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WORKSHOP  BACKGROUND 


Ever  since  the  movie  Star  Wars  showed  Luke  Skywalker  and  R2D2 
teaming  up  to  destroy  the  Death  Star,  there  has  been  considerable 
speculation  as  to  how  an  efficient  pilot-robot  team  could  be 
created.  Since  weight  is  a  critical  design  factor  in  airborne 
systems,  the  literal  building  of  a  pilot-robot  team  has  not  been 
undertaken;  rather,  the  emphasis  shifted  to  incorporating  the 
intelligence  of  the  robot.  As  work  in  this  area  progressed,  such 
terms  as  "electronic  crewmember"  and  "black  box  back  seater”  began 
to  enter  the  vocabulary  of  both  the  crewstation  design  and  computer 
software  communities.  While  the  use  of  these  titles  served  to 
stimulate  thinking  in  the  area  of  human-computer  teamwork,  a  major 
program  was  needed  to  start  the  design  and  implementation  of 
concepts  needed  to  build  an  electronic  crewmember  (EC);  in  the  US 
this  took  the  form  of  the  Pilot,  s  Associate  Program.  The 
establishment  of  the  Pilot, s  Associate  Program  in  1985  gave 
credence  to  the  idea  that  the  building  of  the  brain  of  R2D2,  in 
some  very  simplified  form,  might  be  possible. 

In  the  next  two  years,  numerous  discussions  were  held  to  explore 
some  of  cockpit  ramifications  created  by  the  use  of  a  pilot-EC  team 
within  the  aircraft.  These  discussions  occurred  in  various 
technical  meetings  within  the  US  and  the  UK.  In  one  of  the 
meetings  held  in  the  US,  attended  by  representatives  of 
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the  Air  Force  of  the  Federal  Republic  of  Germany  as  well  as  US 
and  UK  representatives,  the  idea  of  the  present  workshop  was  born. 
Although  progress  on  the  idea  of  a  workshop  concerning  human-EC 
teamwork  continued,  in  1987  an  event  occurred  which  demonstrated 
the  definite  need  for  the  workshop. 

In  April  of  1987,  USAF  representatives  gave  a  paper  at  a  meeting 
of  the  Royal  Aeronautical  Society  in  London  and  again  at  a  meeting 
of  the  Ergonomics  Society  in  Swansea,  Wales.  The  subject  of  the 
paper  was  "Workload  and  Situation  Awareness  in  Future  Aircraft", 
and  a  section  of  the  paper  discussed  workload  sharing  between  the 
pilot  and  the  EC.  During  both  meetings  the  same  kinds  of  questions 
were  asked:  Is  the  pilot  always  in  charge?  Can  the  pilot  and  EC 
really  be  called  a  team?  why  do  you  need  the  pilot  at  all? 

These  thought  provoking  questions  resulted  in  continued 
discussions  with  technical  personnel  in  the  US,  UK  and  FRG,  and  the 
result  was  the  1988  workshop  entitled,  "The  Human-Electronic  Crew: 
Can  They  Work  Together"  (WRDC-TR-89-7008 ) .  Following  the  1988 
workshop,  interest  was  expressed  in  holding  as  additional  meeting 
on  the  topic  of  human-electronic  teamwork.  Sponsorship  was  obtained 
from  organizations  within  the  three  Air  Forces,  and  as  a  result  the 
present  workshop,  which  the  German  Air  Force  generously  agreed  to 
host,  became  a  reality. 
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EXECUTIVE  SUMMARY 


The  meeting  was  divided  into  two  sections:  formal  presentations 
(papers)  and  a  workshop.  The  papers  covered  a  wide  range  of  topics 
ranging  from  artificial  intelligence  (AI)  implementation  issues, 
through  pilot-electronic  crewmember  (EC)  dialogue,  to  the  EC's 
autonomy  and  building  trust  between  the  two  crew  members.  A 
summary  of  the  ideas  from  the  papers  is  given  below: 

Papers 

Relative  to  the  papers  presented  at  the  Workshop  in  1988,  the 
papers  at  the  current  Workshop  reflect  significant  progress  in  the 
examination  of  what  it  actually  takes  to  build  an  EC.  The  papers 
gave  examples  of  a  number  of  expert  systems  (called  "intelligent 
knowledge  base  systems"  by  the  Europeans)  applied  to  well  defined, 
narrow  applications,  e.g.,  air-to-air  tactics  aid,  displays 
manager,  and  a  mission  planner  for  air-to-ground  roles. 

A  second  difference  in  the  papers  relative  to  the  1988  Workshop  was 
progress  in  understanding  how  teams  work  together,  and 
understanding  the  issues  of  the  pilot's  building  trust  and 
confidence  in  the  EC;  a  mathematical  model  of  how  to  relate  human, 
machine,  and  system  accuracies,  as  a  function  of  trust  and 
confidence  in  the  EC  was  presented.  In  the  1988  Workshop  only  the 
words  were  mentioned;  no  methods  of  attacking  this  problem  were 
presented.  Related  to  the  teamwork  issue  was  the  discussion  of 
pilot  inferencing  or  knowing  the  intent  of  the  pilot. 
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Workshop 


After  the  presentation  of  the  papers,  the  second  half  of  the 
meeting  consisted  of  a  workshop;  its  purpose  was  to  form  six  teams 
to  deal  with  AI  technology  and  cockpit  implications  of  the 
technology.  The  teams  were  composed  of  the  three  technical 
disciplines  represented  at  the  conference  —  pilots,  crewstation 
designers,  and  artificial  intelligence  experts.  The  AI  technology 
was  further  subdivided  into  state  of  knowledge,  unresolved  issues, 
and  potential  directions.  At  the  end  of  the  workshop  each  of  the 
six  team  leaders  presented  the  results  of  their  deliberations. 
Below  are  the  overall  views  of  the  different  technical  disciplines 
represented  at  the  workshop. 

Viewpoints  from  the  Workshop  Teams. 

In  the  area  of  AI  software  technology,  it  was  felt  that  converting 
from  Lisp  to  Ada  may  be  more  difficult  than  was  first  anticipated, 
and  the  resulting  code  may  be  computationally  inefficient.  On  the 
positive  side,  a  clear  distinction  was  drawn  between  real  time  as 
it  refers  to  an  avionics  system,  e.g.  30  Hz,  and  real  time  as  it 
refers  to  the  human  time  frame,  e.g.  1  or  2  seconds;  this  has  a 
major  impact  on  the  system  throughput  requirements.  The  aircrew 
issues  dealt  with  building  trust  and  confidence  in  the  EC,  and 
adaptability  of  the  system.  It  appears  that  for  the  near  future 
the  pilot  is  going  to  do  the  adapting;  and  not  the  EC,  since  there 
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are  currently  no  AI  systems  that  truly  learn.  The  crewstation 
issues  dealt  with  how  to  convey  information  efficiently  between  the 
two  members,  and  concentrated  on  display  formats  and  new  control 
techniques . 


CONCLUSION 


The  overall  worth  of  the  Workshop  can  be  summed  up  in  the  comments 
of  a  British  Tornado  pilot  who  came  with  a  healthy  skepticism.  At 
the  end  of  the  Workshop,  he  remarked  that  he  could  see  a  real  value 
in  the  EC.  The  example  he  used  was  guiding  him  safely  home  after  a 
target  strike  when  he  was  low  on  fuel.  He  felt  that  the  EC  could 
be  a  true  lifesaver  in  this  situation. 

Besides  the  technical  information  gathered,  one  of  the  major 
accomplishments  was  the  positive  interchange  among  the  partici¬ 
pants.  There  was  a  genuine  interest  in  sharing  information  and 
ideas  in  order  to  attack  the  common  problem  of  information  overload 
in  the  cockpit.  The  participating  countries  are  striving  to  reach 
a  common  goal,  and  the  ideas  exchanged  in  the  workshop  should  prove 
very  beneficial  to  all  of  them. 
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THE  EFFECT  OF  AN  ARTIFICIALLY  INTELLIGENT  COMPUTER 
ON  THE  COCKPIT  DESIGN  PARADIGM. 

Terry  J.  Emerson  and  John  M.  Reising 
Wright- Patterson  Air  Force  Base,  Ohio,  USA 


SUMMARY 

Artificially  intelligent  (AI)  computers  exist.  Computers  utilizing  knowledge  based 
systems  are  involved  in  such  diverse  activities  as  diagnosing  blood  disease  and 
performing  geological  exploration.  There  are  several  programs  underway  that  are 
investigating  the  use  of  AI  computers  to  create  an  Electronic  Crewmember  (EC).  The 
EC  may  eventually  replace  a  human  crewmember  in  the  cockpit.  The  current  focus  in 
this  area  is  on  the  two -person  fighter/attack  aircraft;  however,  the  concepts  appear 
to  be  expandable  to  systems  having  larger  crews  such  as  multi-crew  transports.  The 
purpose  of  this  paper  is  to  discuss  how  the  emergence  of  knowledge  based  systems 
will  affect  the  crew  station  design  paradigm.  Traditional  aspects  such  as  mission 
and  function  analysis,  task  allocation,  workload  prediction,  etc.,  will  undoubtedly 
be  affected  by  the  availability  of  adaptive  decision  aiding,  intelligent  mission 
management  and  other  EC  functions.  Levels  of  autonomy  and  authority  for  the 
crewmembers,  and  the  need  for  new  paradigms  will  also  be  discussed. 


INTRODUCTION 

Artificially  intelligent  (AI)  computers  are  rapidly  being  developed  for  both 
airborne  and  ground-based  applications.  As  compared  with  systems  utilizing 
conventional  computers,  systems  built  with  AI  computers  will  be  fundamentally 
different  in  their  human- computer  interaction  because  "intelligent  functions  are 
performed  by  both  man  and  computer,  and  initiative  for  action  is  accordingly  assigned 
to  both  man  and  computer"  (Zachary,  Glenn,  &  Hopson,  1981,  p.  100).  Intelligent 
systems  impact  the  crew  station  (CS)  design  process  in  two  important  ways.  First, 
they  can  provide  the  CS  designer  with  an  intelligent  electronic  assistant  to  aid  in 
a  number  of  steps  of  the  overall  design  process  .  Secondly,  AI  can  be  brought  into 
the  aircraft  in  the  form  of  a  pilot's  associate  or  electronic  crewmember  (EC)  (Small, 
Lizza,  &  Zenyuh,  1988).  How  they  specifically  affect  the  CS  design  process  is  the 
subject  of  the  rest  of  the  paper. 

CURRENT  CREVSTATION  DESIGN  PARADIGMS 

The  overall  design  process  involved  in  human-machine  systems  is  well  documented 
(Gagne,  1962).  A  paradigm  specifically  related  to  the  crewstation  design  process  for 
aircraft  is  shown  in  Figure  1.  It  consists  of  five  steps  (Kearns,  1982). 

The  first  step,  Mission  Analysis,  or  problem  definition,  begins  with  a  careful, 
detailed  examination  of  the  intended  operational  use  of  the  system.  This  is  followed 
by  the  derivation  and  documentation  of  total  system  and  individual  component 
requirements.  The  Statement  of  Need  or  requirements  data  published  by  the  future 
user  of  the  system  provides  important  baseline  material  for  this  phase.  Typically, 
the  documentation  produced  in  this  phase  includes  a  mission  description  and 
sequential  listing  of  all  of  the  operations  the  system  must  be  designed  to  perform 
in  its  expected  operational  environment.  It  includes  tasks  performed  by  the 
aircraft,  its  systems,  and  each  of  the  crew  members  (ORLOC,  1981).  To  augment  this 
data,  the  designer  (or  design  team)  may  also  perform  an  analysis  of  the  decisions 
that  have  to  be  made  by  crew  members  as  the  mission  progresses.  To  be  successful 
each  step  in  the  process  needs  strong  user  Involvement.  An  essential  output  of  this 
step  is  the  Identification  of  the  information  that  is  necessary  for  the  crew  to 
perform  the  mission. 
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The  second  step  in  the  cockpit  design  process  is  depicted  in  Figure  1  as 
Preliminary  Design  but  is  probably  more  often  referred  to  as  "defining  a  solution". 
During  this  phase  most  of  the  activity  is  devoted  to  generating  a  design.  The 
requirements  are  reviewed  and  decisions  made  regarding  the  way  functions  will  be 
carried  out  and  information  will  be  provided.  The  dividing  line  between  problem 
definition  and  solution  development  is  often  vague.  Specific  designs  affect  the 
timelines,  timelines  can  reveal  workload  problems,  which  in  turn  may  have  an  impact 
on  the  scenario  --  all  of  which  suggests  that  the  process  may  iterate  several  times. 


A  key  element  in  the  evolving  design  is  operator  or  user  involvement.  The 
sustained  participation  of  operators  with  relevant  experience  results  in  fewer  false 
starts,  better  insight  into  how  (and  why)  the  mission  is  performed  today,  and  a 
great  savings  of  time  in  the  latter  phases  of  the  project. 

The  last  three  steps  are  each  very  critical  to  the  successful  completion  of  an 
effective  and  proven  cockpit  de»ign;  they  are  also  interdependent  in  that  the  Mockup 
Evaluation  provides  recommended  configurations  for  simulation,  and  the  Simulation 
Evaluation  yields  configurations  for  the  In-flight  Validation.  For  the  purpose  of 
this  discussion,  these  final  steps  are  combined  to  provide  "Solution  Evaluation". 
Once  again,  there  may  not  be  a  clear  break  between  this  phase  and  the  solution 
definition  phase.  It  has  been  observed  that  most  designers,  design,  evaluate, 
redesign,  etc.,  as  they  go.  The  transition  occurs  when  formal,  total-mission, 
total -system,  pilot- in- the- loop  evaluations  begin.  But  even  then,  decisions  made 
during  the  problem  and  solution  definition  steps  are  often  revisited,  changes  made, 
and  simulation  sessions  or  even  flight  tests  rescheduled  -•  all  resulting  in,  as 
previously  suggested,  a  very  iterative  or  cyclic  process. 

Early  in  the  process,  the  evaluations  are  both  part  task  and  part  mission.  As 
the  design  matures  the  mock-ups  and  simulators  reach  higher  fidelity  and  the 
evaluations  eventually  become  full-task,  full  mission.  Obviously,  user  participation 
in  the  last  three  steps,  mock-up,  simulation,  and  flight  test  is  crucial  to  achieving 
the  goal  of  producing  a  validated  cockpit  design. 

INTELLIGENT  DESIGNER'S  ASSISTANT 

Several  years  ago  USAF  engineers  conceptualized  a  system  called  the  Rapidly 
Reconf igurable  Crewstation  (RRC)  [Fileccia,  Relslng  &  Williams,  1988].  The  system 
in  its  final  form  would  have  had  a  strong  impact  on  the  efficacy  of  the  design 
paradigm  just  described.  Design  changes  during  the  process  would  be  easier  and 
faster;  the  necessary  Iterations  often  referred  to  could  be  accomplished  rapidly, 
and  user  participation  would  be  much  more  efficient,  i.e.,  cockpit  redesigns  would 
be  done  in  less  than  a  day  rather  than  in  months  as  is  the  case  today. 

The  RRC  as  conceived  consisted  of  an  automated  layout  center,  automatic  software 
generation,  communications ,  graphics,  real-time  simulation,  operator's  consoles  etc. 
A  knowledge  based  system  or  artificially  intelligent  computer,  one  of  the  RRC 
subsystems,  was  to  have  served  as  the  cockpit  designer's  electronic  assistant.  The 
assistant  would  Integrate  human  engineering  principles  with  the  more  traditional 
system  design  disciplines  at  an  early  stage  in  the  design  paradigm  to  provide  the 
designer  with  assistance  in  the  problem  and  solution  definition.  The  knowledge  based 
system  would  provide  models  for  simulation,  human  behavior,  performance,  graphics 
and  other  tools.  (Pacific  Microelectronics,  1989) 

The  RRC  would  not  have  changed  the  framework  of  the  fundamental  cockpit  design 
paradigm  but,  with  its  artificially  intelligent  computer,  would  have  had  a  very 
significant  time  reducing  impact  on  all  of  the  elements. 

The  basic  concept  of  RRC  remains  valid  and  it  is  continuing  to  evolve  through 
industrial  interest  and  activity.  The  sizeable  USAF  effort  to  make  it  happen  within 
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a  few  years  was  not  able  to  survive  recent  budgets  cuts.  The  USAF  Cockpit  Automation 
Technology  (CAT)  program,  began  in  1986,  has  survived  to  automate  many  of  the  tools 
and  models  which  support  the  cockpit  design  paradigm.  The  CAT  process  employs  a 
variety  of  analytical  and  empirical  approaches  (Kulwicki,  McDaniel  &  Guadagna,  1987) . 

The  paradigm  Just  described  has  worked  very  well  with  systems  that  had  a  the 
computer  which  was  always  provided  direction  by  the  human  to  perform  primarily  data 
processing  tasks,  but  will  it  be  adequate  for  the  design  of  systems  in  which  the 
computers  can  initiate  their  own  actions  and  perform  a  far  greater  variety  of  tasks? 

THE  PARADIGM  FOR  CREVSTATION  NEEDS  TO  BE  MODIFIED. 

The  overall  design  paradigm  is  sound.  However,  modifications  to  components  of 
the  paradigm  are  needed.  Specifically,  the  information  requirements,  level  of 
automation,  and  evaluation/validation  sections  need  to  be  modified  if  an  artificially 
intelligent  computer  is  included  in  an  aircraft  system  to  create  or  provide  an  EC. 

Information  Requirements.  A  key  feature  of  the  design  paradigm  to  be  affected 
by  the  inclusion  of  the  EC  is  the  function  allocation  aspect  of  the  information 
requirements  section.  Once  it  is  known,  in  broad  terms,  what  information  or  data  will 
be  provided  to  the  human  and  to  the  machine,  and  what  their  capabilities  are,  the 
designer  may  begin  the  allocation  of  functions  between  the  two.  In  the  classic 
paradigm,  function  allocation  is  static;  it  is  performed  early  in  the  design  process 
and  is  essentially  unmodified  thereafter.  This  will  not  be  true  when  an  EC  is 
included;  a  realtime,  dynamic  task  allocation  will  have  to  be  a  part  of  the  design 
paradigm. 

Dynamic  task  allocation  means  that  workload  can  be  shifted  between  the  pilot  and 
the  EC  in  realtime  during  the  course  of  the  mission  (Emerson,  Reising  & 
Britten-Austin,  1987).  This  exchange  can  occur  both  consciously  and  unconsciously 
as  far  as  the  pilot  is  concerned;  the  former  involves  active  consent  by  the  pilot, 
while  the  latter  involves  implied  consent.  In  the  conscious  case,  the  task 
allocation  would  be  communicated  at  a  very  high  level  with  a  few  key  actions  or 
words.  For  example,  in  the  case  of  a  system  failure,  after  being  informed,  the  pilot 
could  merely  say,  "Fix  it."  The  EC  then  would  carry  out  all  subsequent  details. 
The  same  high  level  interaction  between  the  team  members  could  also  occur  in  the  case 
of  a  mission  change.  The  pilot  could  say,  "Nev.  target  --  railroad  bridge  B."  The 
EC  would  execute  all  the  navigation,  threat  avoidance,  fuel  management,  and  stores 
selection  tasks  needed  to  carry  out  the  mission.  Through  verbal  commands,  the  pilot 
consciously  reduces  his  own  workload  by  dynamically  allocating  tasks  to  the  EC.  It 
may  be  possible,  however,  to  have  a  much  more  subtle  dynamic  task  allocation  which 
involves  Implied  consent  by  the  pilot  either  before  or  during  the  mission. 

In  describing  the  mission,  knowing  the  functions  and  capabilities  of  the  EC,  the 
designer  could  incorporate  the  EC's  allowable  workload  for  each  phase  into  the 
knowledge  base.  The  level  would  be  determined  by  data  processing  capacity,  speed, 
etc.  Once  the  overall  mission  has  been  established  and  committed  to,  the  pilot-EC 
team  would  then  be  responsible  for  completing  the  mission,  and  the  level  of  workload 
for  each  member  would  be  adjusted,  if  necessary,  in  realtime  to  successfully  complete 
the  mission.  The  pilot  would  not  have  to  command  the  EC  to  perform  every  task.  For 
example,  if  multiple  missiles  were  fired  at  the  aircraft  and  the  pilot  sighted  one 
of  them,  he  might  choose  to  defeat  it  by  a  jinking  maneuver.  This  kind  of  maneuver 
can  be  quite  difficult  and  in  most  cases  will  occupy  most,  if  not  all,  of  the  pilot's 
resources.  The  EC,  without  waiting  for  permission,  would  employ  its  own  resources 
(chaff,  flares,  and  electronic  countermeasures)  against  the  remaining  missiles .  The 
key  aspect  of  this  scenario  is  the  implied  permission  and  automatic  task  shedding 
based  on  the  team's  acceptance  of  the  mission  objectives  and  the  overall  governing 
rules  of  operation. 

Levels  of  Automation.  The  inclusion  of  an  EC  could  also  have  a  dramatic  effect 
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on  the  Level  of  Automation  portion  of  the  Preliminary  Design  phase  of  the  paradigm. 
The  main  difference  that  AI  contributes  is  providing  for  differing  levels  of  autonomy 
(LOA)  for  the  EC.  "LOA  defines  a  small  set  (’levels')  of  system  configurations,  each 
configuration  specifying  the  degree  of  automation  or  autonomy  (an  'operational 
relationship')  at  which  each  particular  subfunction  performs.  The  pilot  sets  or 
resets  the  LOA  to  a  particular  level  as  a  consequence  of  mission  planning, 
anticipated  contingencies,  or  inflight  needs"  (Krobusek,  Boys,  &  Palko,  1988,  p. 
124.)  Unlike  the  level  of  automation  subfunction  shown  in  Figure  1,  which  is 
determined  at  the  preliminary  design  stage  and  essentially  frozen,  the  autonomy 
levels  of  the  EC  open  up  the  ability  to  assign  different  authority  levels  for  various 
mission  phases. 

Evaluatlon/Validation.  During  this  phase  of  the  design  process,  the  human  and 
computer  are  built  into  a  team.  In  the  classic  paradigm,  the  capabilities  of  the 
computer  were  relatively  well  known  early  in  the  evaluation  phases,  and  after  the 
usual  difficulties  experienced  during  the  "burn  in"  period,  the  human  could  trust 
the  computer  to  perform  in  a  consistent  manner.  However,  in  a  system  where  the 
computer  can  have  differing  levels  of  autonomy  and  initiate  action  on  its  own,  the 
buildup  of  trust  becomes  crucial. 

This  trust  can  be  envisioned  to  develop  in  three  stages.  At  first  trust  is  based 
on  the  predictability  of  individual  behaviors.  In  the  second  stage  trust  is  based 
on  dependability.  "...  Dependability  may  be  thought  of  as  a  summary  statistic  of  an 
accumulation  of  behavioural  evidence ,  which  expressed  the  extent  to  which  a  person 
can  be  relied  upon."  (Muir,  1987,  p.532).  In  the  third  stage  of  trust,  faith  is  the 
major  component  because  one  team  member  is  willing  to  bet  that  the  other  member  will 
be  dependable  in  the  future. 

Once  the  trust  is  built  between  the  crew  member  and  the  EC,  the  continued  overall 
efficiency  of  the  system  depends  on  such  factors  as  machine  accuracy,  compliance  with 
the  suggestions  of  the  EC  (also  known  as  a  decision  aid),  and  degree  of  faith  in  the 
continued  accuracy  of  the  decision  aid  (Riley,  1989).  Riley's  message  is  that  the 
relationships  between  the  pilot  and  the  EC  can  be  very  dynamic,  and  we  are  just 
beginning  to  understand  these  relationships. 

CONCLUSION 

The  impact  of  artificially  intelligent  computers  on  the  crew  station  design 
process  will  leave  the  overall  paradigm  intact  but  will  substantially  affect 
subsections  such  as  information  requirements,  levels  of  automation,  and 
evaluation/validation.  It  may  take  longer  to  build  an  effective  team,  but  the 
performance  capability  of  the  team  has  the  potential  of  being  orders  of  magnitudes 
beyond  current  systems. 
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THE  HUMAN- ELECTRONIC  CREW:  AN  OPERATOR'S  PERSPECTIVE 


Lt  Cdr  M.  Llewellyn- Jones 
Ministry  of  Defence,  UK 

It  is  my  belief  that  in  common  with  the  air  combat  fighter,  the 
interdiction  aircraft  and  the  battle-field  helicopter,  modern  anti¬ 
submarine  warfare  (or  ASW)  helicopters  need  some  automatic  aiding  if  sensor 
data  i9  to  be  correlated  and  then  assimilated  by  the  human  crew  so  that  the 
best  tactical  solution  is  selected  to  optimise  operational  performance. 

The  objectives  of  this  paper  are  to  provide: 

*  an  understanding  of  the  complexity  of  modern  ASW  helicopter 
mission  systems, 

*  an  insight  into  the  character  and  pace  of  an  ASW  engagement, 
and , 

*  an  outline  of  the  challenges  to  be  met  if  expert  system 
technologies  are  to  be  implemented. 

The  structure  of  a  modern  ASW  helicopter  mission  system  as  shown  in  the 
accompanying  diagram  consists  of: 

*  a  mission  management  system:  sensors  (sonics,  active  dipping 
sonar,  radar,  ESM,  MAD),  weapons  (torpedoes  and  depth  charges), 

*  an  aircraft  management  system:  navigation,  communications,  data 
link  and  (although  not  shown)  flight  and  engine  control  system, 

*  all  linked  together  by  data  bases  and  controlled  by  mission  and 
aircraft  management  computers. 

So,  if  we  can  accurately  define  the  interfaces  and  functions  of  our  mission 
system,  why  is  there  a  need  for  automatic  tactical  aiding  for  the  crew?  I 
contend  that,  even  if  the  mission  system  is  successfully  integrated,  crew 
workload  will  remain  very  high  in  an  ASW  helicopter. 

Although  modern  ASW  sensors  are  able  to  detect  target  radiated  noise,  the 
source  level  is  very  weak  and  passes  through  a  largely  unpredictable  medium 
-  the  sea.  The  resultant  target  signatures  vary  considerably  depending  on 
the  submarine’s  speed  and  depth  as  well  as  its  aspect  relative  to  the 
sensors.  Consequently,  contact  is  at  best  intermittent  and  often  of  short 
duration.  Acoustic  sensors  only  provide  a  low  data  rate.  It  is  therefore 
difficult  to  identify  manoeuvres  by  the  submarine,  without  significant 
operator  interpretation  of  all  the  acoustic  data. 

If  the  target  is  alerted  to  the  presence  of  the  helicopter  then  it  may 
evade  vigorously  by  making  best  use  of  speed  and  the  local  acoustic 
conditions,  including  wrecks,  and  other  bottom  features.  If  the  submarine 
believes  he  is  under  imminent  threat  of  an  attack  he  may  deploy  acoustic 
countermeasures  of  the  target’s  position,  course  and  speed. 

To  overcome  these  problems  great  emphasis  has  been  placed  on  improving  the 
performance  of  our  sensors,  not  only  to  detect  the  submarine  and  maintain 
contact  but  also  to  produce  an  accurate  track  from  which  further  sensor 
deployments  or  attack  points  can  be  predicted.  However,  improved 
technology  does  not  necessarily  reduce  the  operator ’9  workload,  because: 

*  the  crew  must  make  selections  from  a  variety  of  sensors  and  to 
decide  on  the  most  advantageous  positions  to  deploy  them 
relative  to  the  target. 

*  they  must  choose  the  right  operating  modes. 
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*  they  must  carry  out  low-level  data  fusion  and  correlation,  while 
monitoring  the  sensors,  and, 

*  they  must  have  detailed  knowledge  of  both  target  intelligence 
and  own  system  capability  to  fully  exploit  the  submarine’s 
signature . 

It  can  be  imagined  that  during  sorties  of  this  nature,  the  crew  have  to 
deal  with  a  high  workload  caused  by  a  multitude  of  concurrent,  or  near 
concurrent,  activities  happening  over  a  short  time-span.  So,  it  seems 
that  the  likely  applications  for  real  time  expert  systems  in  an  ASW 
helicopter  are: 

*  a  tactical  advisor, 

*  a  sensor  manager,  and, 

*  a  classification  aid. 

Of  these  the  UK  MOD  Operational  Requirements  Directorate  is  actively 
involved  with  research  projects  into  a  tactical  and  sensor  advisor  and  is 
keenly  interested  in  other  research  into  classification  aids. 

So  if  such  technologies  are  to  be  implemented  what  are  the  challenges? 

*  In  today’s  political  and  economic  scene  we  must  positively 
justify  each  step  of  our  procurement  process,  whether  for 
research,  a  demonstrator,  feasibility  studies,  development  or 
production.  The  operational  benefits  need  to  be  established  and 
the  price  must  be  affordable.  This  applies  to  the  potential  use 
of  expert  systems. 

*  There  is  a  considerable  investment  in  aircrew  training.  It  will 
be  a  challenge  to  persuade  the  military  staffs  that  expert  and 
other  novel  technologies  will  not  replace  aircrew  expertise  but 
allow  the  aircrew  to  be  more  effective. 

*  We  need  to  establish  which  problems  can  be  solved  by  the 
application  of  expert  system  technology.  I  have  already 
suggested  that  automation  itself  cannot  provide  all  the 
solutions.  Often  automation  simply  generates  more  data,  and  so 
makes  the  operator’s  task  more  difficult.  What  we  need  is  to 
ensure  that  these  technologies  address  the  central  issue  of 
managing  the  data  and  presenting  it  to  the  operator  in  a  clear 
and  readily  assimilable  form  together  with  the  tactical  advice 
he  needs  to  fight  the  battle  at  that  moment,  especially  in 
highly  dynamic  and  multi-threat  environments. 

*  If  expert  systems  are  to  provide  this  sort  of  tactical  advice 
then  the  tactical  advisor: 

*  must  be  able  to  interface  with  the  sensors  and  aircraft 
systems , 

*  the  advisor  must  be  able  to  communicate  its  information  to 
the  human  crew.  So,  the  whole  issue  of  the  human-machine 
interface  needs  to  be  explored. 

*  The  expert  system  must  also  be  able  to  take  account  of  the 
balance  between  risk  to  survival  and  mission  achievement. 

*  There  may  be  a  need  to  dynamically  share  the  management  of  the 
aircraft  and  mission  systems  between  the  human  and  electronic 
crew,  depending  on  the  prevailing  conditions. 

*  All  this  advice  needs  to  be  provided  to  the  crew  in  real-time. 
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*  But,  however  clever  the  electronic  crew  becomes  we  must  always 
allow  for  the  intuition  and  initiative  of  the  human  crew  by 
allowing  interaction  between  the  human  and  electronic  crew. 

*  We  need  rapid,  flexible  and  cheap  methods  of  updating  the 
advice.  The  expert  system  elements  must  therefore  be  "modular" 
so  that  amendments  can  be  made  without  disrupting  the  remainder 
of  the  mission  system. 

*  In  dealing  with  novel  technologies  we  need  to: 

*  convince  the  operators  of  the  benefits  of  expert  systems, 
and , 

*  establish  the  operator’s  confidence  that  expert  systems 
will  provide  reliable  advice. 

*  Lastly,  we  need  to  develop  formal  methodologies  to  validate 
expert  systems  because: 

*  it  is  no  use  providing  such  systems  if  they  cannot  achieve 
CA  release.  For  a  CA  release  we  need  to  be  able: 

*  to  confirm  the  technology  is  safe,  and 

*  to  measure  the  performance  of  the  system. 

Whilst  I  have  explained  in  some  detail  the  relevance  of  expert  system 
technology  to  my  particular  domain  of  interest,  the  issues,  problems  and 
potential  benefits  are  common  to  all  military  users  of  experts  systems. 
Hopefully  during  the  Workshop  we  will  address  the  challenges  I  have 
outlined.  We  will  then  be  able  to  return  to  our  laboratories  and  staff 
desks  with  more  confidence  in  our  ability  to  convince  the  decision  makers 
and  fund  managers  of  the  value  of  expert  system  technology  for  optimising 
mission  effectiveness. 
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ISSUES  IN  REACTIVE  RESOURCE  ALLOCATION  FOR  NAVAL  SYSTEMS. 


George  Brander 


Ministry  of  Defence.  Procurement  Executive 
Admiralty  Research  Establishment 
Portsdown,  Portsmouth  P06  4AA 


Summary 

An  analogy  is  drawn  between  the  tasks  and  functions  envisaged  for  an  electronic  co-pitot 
and  the  role  of  a  Pricipal  Warfare  Officer  (PWO)  in  a  surface  warship.  Analytical  decision  making 
models  are  deemed  insufficient  in  the  reactive  resource  allocation  task  domain  and  Klein's  model 
of  Recognition  Primed  Decisions  seems  to  offer  a  more  appropriate  model  on  which  to  base  further 
investigations.  Research  on  Naval  reactive  resource  allocation  is  outlined  together  with  a  way 
ahead  for  future  work  to  explore  the  cognitive  nature  of  the  whole  command  and  control  task  and  a 
decision  support  environment. 

Introduction. 

Two  years  ago,  at  the  previous  Workshop,  some  of  the  issues  pertaining  to  the  development 
of  an  electronic  co-pilot  were  debated.  These  included: 

the  need  for  the  KBS  component  to  appreciate  the  intenttonality  of  the  Pitot,  and 

the  prospect  of  multiple  cooperating  expert  systems  and  teaming  concepts. 

My  thesis  is  that  an  analogue  of  a  system  containing  these  kinds  of  features  already  exists  in 
the  operations  room  of  a  warship  and  that  work  in  this  Naval  domain  may  therefore  be  generalisable 
to  a  wider  range  of  applications  including  the  fighter  cockpit. 

The  role  of  Principal  Warfare  Officer  In  the  Operations  Room. 

The  PWO's  primary  task  is,  in  essence,  the  defence  and  fighting  of  the  ship.  In  this  sense  he 
is  acting  as  the  Captain's  co-pilot  because  he  is  responsible  to  the  Ship's  Commanding  Officer 
who  is  in  overall  command  of  the  Ship  and  concerned,  above  all,  with  Ship  safety.  The  PWO 
therefore  needs  to  understand  the  intenttonality  of  the  Captain;  that  is  how  he  wants  to  operate 
and  what  information  he  will  wish  to  know. 

The  PWO  is  also  in  command  of  the  Operations  Room  and  the  people  within  it.  There  may  be 
up  to  thirty  of  them  in  groups  dedicated  to  particular  warfare  areas  or  sensor  and  weapon  systems. 
The  PWO  is  the  executive  who  directs,  monitors  and  coordinates  the  activities  of  various  teams, 
expert  systems  in  their  own  right,  who  are  responsible  for  the  detailed  control  of  sensors  and 
weapons.  The  increasing  trend  towards  automation  means  that  many  of  the  individual  sensor  and 
weapon  systems  are  autonomous  yet  the  PWO  will  still  have  veto  authority  over  them.  In  this 
sense  he  is  the  pitot  with  the  entire  Ops  Room  acting  as  his  pitot’s  associate. 

The  PWO  thus  needs  to  have  a  good  knowlege  or  understanding  of  his  Commanding 
Officer  and  a  detailed  working  knowledge  of  the  equipment  and  resources  available  to  him.  In 
order  to  make  the  best  use  of  these  resources  the  PWO  additionally  needs  to  be  a  gcod  man 
manager:  in  the  Ops  Room  he  is  the  head  of  a  team,  many  of  whose  members  are  experts  in  their 
own  field,  and  he  must  ensure  that  they  are  motivated  to  support  each  other,  to  provide 
information  as  needed  and  tc  cooperate  in  support  of  the  team's  objectives. 

If  the  thesis  that  the  PWO  is  a  role  model  for  an  electronic  co-pitot  system  is  correct  then  my 
argument  is  that  research  underway  at  the  Admiralty  Research  Establishment  which  attempts  to 
support  the  decision  making  tasks  of  a  PWO  will  provide  greater  insight  into  the  nature  of  these 
types  of  tasks  and  the  human  expertise  and  cognitive  processes  that  are  actually  used. 

Models  of  decision  making. 

In  order  to  provide  effective  decision  support  it  is  necessary  to  have  a  good  model  of  how 
human  experts  make  decisions  and  what  information  they  actually  use.  There  is  a  plethora  of 
models  of  a  decision  process,  ranging  from  Miller  Galanter  and  Pribram’s  TOTE"  to  WohCs  "SHOR" 
model,  but  as  Brian  Sherwood-Jones  notes  (REF  1)  these  models  only  describe  a  hypothesised 
process,  not  necessarily  what  people  actually  do.  This  is  further  amplified  in  that  it  is  often 
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impossible  to  observe  decision  points  -  things  just  seem  to  happen  and  only  in  retrospect  can 
decision  makers  justify  what  they  did  or  didnl  do.  This  obviously  makes  the  area  rather  hard  to 
study  and  the  effective  design  of  support  systems  rather  difficult:  decades  of  research  into  optimal 
decision  theory  have  provided  little  in  the  way  of  acceptable  real-time  operational  decision  aids. 
However  a  way  ahead  may  be  indicated  by  Klein's  theory  of  Recognition  Primed  Decisions.  (REF 
2)  (See  Figure  1 ) 

Figure  1  "Recognition  Primed  Decision  Model"  -  Klein  1989 


In  essence  Klein  argues  that  expert  human  decision  making  under  time-stress  is  non-analytic 
and  certainly  does  not  fit  into  any  optimal  decision  theory  framework.  He  suggests  that  experts 
strive  for  adequate  decisions  by  matching  responses  to  problems  identified  or  recognised  as 
typical.  The  nature  of  expertise  is  such  that  these  suitable,  satisficing  responses  are  generated 
very  rapidly;  there  appears  to  be  no  concurrent  evaluation  of  options.  Klein  continues  that  what 
might  occur  instead  is  that  the  expert  visualises  the  chosen  response  to  verify  that  it  will  achieve 
the  aim  and  where  it  won't  he  will  try  to  adapt  if  so  that  it  will.  Only  if  the  response  seems 
unworkable  will  he  move  on  to  a  new  one.  Thus  experts  seem  to  know  intuitively  the  best  decision 
and  can  rapidly  test  it  to  find  ways  of  disproving  it  whereas  novices  seem  to  be  more  inclined  to 
compare  options,  searching  for  evidence  to  confirm  early  hypotheses. 

Decision  making  In  Naval  context. 

Klein's  model  is  intuitively  attractive  in  a  Naval  context  because,  based  on  our  experiences. 
PWO's  seem  to  operate  in  a  remarkably  similar  fashion,  although  this  has  yet  to  be  tested.  PWO's 
are  trained  and  subsequently  observed  to  activate  procedural  responses  to  highly  time-stressed 
events  such  as  the  detection  of  a  missile  head  flying  towards  them.  We  are  now  in  the  area  termed 
resource  allocation:  more  specifically,  reactive  resource  allocation.  The  response  procedures  may 
be  very  complex  (turn  off  radar,  start  jamming,  fire  chaff,  manoeuvre  ship,  activate  targeting  radar, 
etc)  and  usually  involve  several  teams  within  the  Ops  Room.  Additionally  the  procedures  may  be 
affected  by  constraints  imposed  by  a  higher  authority  (Rules  of  Engagement,  Force  Level  plans)  or 
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by  physical  geometry  (collision  situations).  The  procedures  are  well  rehearsed  by  the  C  ps  Room 
teams  but  are  too  time  critical  for  much  adaptation  or  on-line  tuning,  they  just  have  to  hap  pen.  The 
problem  is,  however,  that  while  one  procedure  can  be  carried  out  effectively,  if  a  battle  scenario 
requires  two  or  more  concurrent  procedures  to  be  activated  using  the  same  set  of  resoL  ces,  the 
teams  may  be  unable  to  cope.  The  PWO  is  likely  to  become  overloaded  or  the  procedures  may 
interact  to  such  an  extent  that  only  one  is  possible  -  that  is  the  generation  of  a  composite  or  new 
satisficing  procedure  is  impossible  within  the  timescales  of  the  threat.  Under  these  circumstances, 
say  the  simultaneous  attack  by  a  missile  and  a  torpedo,  anecdotal  evidence  suggests  that  the 
coping  response  is  likely  to  entail  activating  one  procedure  alone  ("let  us  evade  the  torpedo  rather 
than  the  missiles  because  a  big  hole  below  the  water-line  is  worse  than  a  hole  in  the  deck")  To 
some  extent  this  is  another  example  of  a  satisficing  decision:  after  all  it  is  generally  believed  tl  at  it 
is  better  to  do  something  than  to  just  sit  there,  undecided,  with  a  sinking  feeling.  I  believe  it  is  >n 
this  area  that  automated  real-time  decision  support  does  have  something  to  offer. 

Reactive  Resource  Allocation. 

A  contract  underway  with  Ferranti  International  (Naval  Command  and  Control  Division)  aims  to 
produce  a  reactive  resource  allocation  demonstrator  early  next  year.  Entitled  RRASSL  (Reactive 
Resource  Allocation  at  Single  Ship  Level)  the  demonstrator  will  use  KBS  techniques  to  generate 
responses  to  a  range  of  attacks  upon  a  surface  ship.  By  firing  rules  appropriate  to  each  threat 
detection  it  is  anticipated  that  RRASSL  will  be  able  to  interleave  procedures  and  produce 
appropriate,  optimised  responses  to  meet  combinations  of  threats.  These  new  procedures  will 
be  presented  to  the  PWO  as  a  list  of  recommended  actions  which  he  will  have  the  opportunity  to 
accept  or  reject.  In  addition  the  system  will  present  a  predictive  display  indicating  the  various  time 
frames  within  which  actions  have  to  occur  and  will  be  able  to  explain  the  rules  which  have  triggered 
the  individual  resonses. 

There  are  many  problems  in  the  design  of  displays  to  represent  the  extra  complexify  of  the 
time  dimension  which  we  intend  to  explore.  In  addition  how  well  a  PWO  will  accept  advice  and 
recommendations  at  the  time  he  is  highly  stressed  we  intend  to  examine  by  means  of  gaming  the 
system  and  its  user  against  increasingly  complex  scenarios.  T'  _.  a  will  he  to  test  that  the  system 
can  cope  with  single  threat  scenarios  and  generate  *he  same  procedures  as  the  PWO's 
themselves  It  is  assumed  that  the  procedures  'o.  single  threats  have,  to  some  extent,  been 
optimised  by  the  tactical  specialists.  Eventuauy  we  hope  to  take  the  users  into  high  stress,  multiple 
conflicting  threat  scenarios  where  we  can  examine  their  decision  strategies  and  where  they  begin 
to  breakdown.  This  is  the  area  where  RRASSI  ic  hoped  to  demonstrate  the  advantages  of  real¬ 
time  KBS  and  where  the  use  of  an  interactive  scenahc  generator  should  allow  assessment  of 
survivability  ana  effectiveness. 

There  is  some  concern  that  the  optimised  responses  produced  by  RRASSL  may  not  be 
readily  accepted  by  the  users,  if  at  odds  with  their  intuitive  decision  making  or  their  individual 
cognitive  styles.  Additionally,  users  may  have  no  basis  upon  which  to  accept  or  reject  the 
recommended  actions  of  RRASSL  in  real  time  because  it  will  be  periorming  calculations  they 
cannot  do  or,  perhaps,  even  proposing  responses  they  cannot  recognise.  As  a  consequence, 
survivability  and  effectiveness  must  be  treated  as  the  criteria  of  success  and  retrospectively 
evaluated.  It  seems  that  users  would  often  prefer  to  fire  missiles  at  a  threat  rather  than  use  soft-kill 
weapons  because  this  "something  that  goes  bang"  seems  to  give  them  more  confidence,  even  <f 
they  have  been  shown  that  the  probability  of  success  is  less.  This  is  perhaps  one  good  reason  why 
KBS  might  be  more  successful  than  humans  in  .his  type  of  responsive  system  under  extreme  time 
pressure 

Another  incidental  advantage  of  RRASSL  may  be  its  value  as  a  training  aid  in  that  it  could 
enable  novice  PWO's  to  sample  many  situations  and  develop  their  experience  and  abilities  to  react 
to  various  threat  scenarios.  After  all  novices  are  often  taught  by  rather  analytical  means  and  do  not 
become  experts  until  they  have  rehearsed  and  applied  their  rules  in  many  settings  and  developed 
their  operational  expertise.  Not  only  would  this  "system  as  a  training  aid"  concept  be  a  mechanism 
for  developing  human  expertise  it  would  enable  the  user  to  develop  his  confidence  and  trust  in  the 
operational  system  and  to  enrich  his  understanding  of  complex  multiple  threat  scenarios. 

The  human  contribution. 

But  this  seems  to  be  arguing  the  case  for  automation  with  little  regard  for  the  human 
contribution  to  the  system  and  seems  to  ignore  the  nature  of  expertise  as  described  by  Klein.  The 
problem  is  that  if  human  experts  do  operate  according  to  Klein's  model  in  the  time-stressed  area  of 
reactive  resource  allocation,  they  may  do  so  for  the  good  reason  that  they  are  unable  to  perform 
concurrent  evaluation  One  may  speculate  that  this  may  be  the  case  or  rt  may  be  that  experts  have 


no  way  of  articulating  concurrent  processing  and  researchers  no  operational  definition  of  what  to 
look  for.  Alternatively,  experts  may  not  have  the  time  or  processing  capability  to  interleave  several 
procedures  (thereby  generating  a  new  one)  but  yet  have  to  find  a  solution  which  is  adequate. 
Returning  to  the  whole  task  of  the  Ops  Room  and,  by  implication,  the  PWO  himself  we  envisage 
that  the  task  involves  data  fusion,  situation  assessment  and  resource  allocation.  Note  this  is  a  high 
level  system  description  (for  implementation  purposes)  rather  than  a  process  model  (see  Figure  2). 
The  functions  are  rather  artificial  distinctions:  they  do  not  appear  «o  happen  in  serial  and  I  do  not 
believe  that  it  is  possible  to  observe  operators  and  classify  their  behaviour  according  to  these 
categories. 

Figure  2 


I  agree,  with  Klein,  that  human  expertise  really  resides  in  the  ability  to  recognise  the  problem 
and  identify  typical  features,  that  is  situation  assessment.  The  PWO,  as  is  any  military  commander, 
is  aiming  to  outmanoeuvre  the  enemy,  to  gain  the  tactical  high  ground,  where  he  can  see  and 
dictate  the  course  of  the  battle  to  his  own  advantage  and  to  plan  his  campaign  so  that  he  is  not 
forced  into  time-stressed  defensive  actions. 

Research  at  the  Admiralty  Research  Establishment. 

The  work  at  ARE,  in  progress  and  planned,  addresses  the  whole  area  of  surface  ship 
command  and  control  and  aims  to  tackle  the  issues  I  have  been  discussing. 

Data  fusion  is  the  starting  point  in  that  it  reduces  the  complexity  of  the  data  gathering  and 
sensor  fusion  task  by  presenting  the  PWO  with  a  reliable  tactical  picture  in  real-time.  The  work  on  a 
KBS  data  fusion  demonstrator,  presented  at  the  previous  Workshop  (REF  3)  is  midway  through 
implementation  and  sea  trials  of  the  system  are  due  to  begin  in  1992  on  board  a  Type  23  Frigate. 

The  next  stage  is  to  implement  a  reactive  resource  allocation  system.  As  I  have  mentioned, 
we  hope  to  begin  exploring  a  prototype  RRASSL  in  March  1991,  retaining  the  option  of  building 
an  operational  RRASSL  prototype  at  a  later  stage  to  coincide  with  the  sea  trials  of  the  data  fusion 
technology  demonstrator. 

This  means  that  we  will  have  automation  at  the  input  end  and  the  output  of  the  command  and 
control  process.  Our  intention  is  to  utilise  these  two  demonstrators  to  enable  us  to  identify  the 
functions  and  processes  necessary  to  complete  the  system  by  transforming  the  output  of  one  into 
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(he  input  for  the  other.  This  area,  currently  termed  situation  assessment,  is  the  most  neb  'lous  and 
difficult  to  address:  it  is  hoped  that  by  varying  the  input  and  output  stages  we  can  treat  situation 
assessment  as  a  black  box  and  begin  to  infer  what  it  is  and  how  it  must  operate. 

Initial  thoughts  were  that  situation  assessment  involved  interpretation  of  the  tactical  picture 
and  the  generation  of  a  prioritised  threat  list.  Klein  suggests  that  situation  assessment  involves 
making  inferences  about  the  nature  of  the  problem  thereby  making  response  selection  easier 
when  it  has  to  happen.  This  is  the  area  where  the  PWO  operates  with  uncertain  information,  trying 
to  identify  the  enemy's  intentions  and  to  predispose  his  system,  including  his  resources  and 
response  procedures  to  meet  whatever  might  happen.  Here  intuition  and  innovative  responses 
have  their  rightful  place.  In  addition  there  is  more  time  for  the  process  of  imagining  "whet  if" 
situations.  The  ability  to  try  out  typical  threat  scenarios  and  walk  through  the  responses  generated 
by  a  RRASSL  system  would  assist  the  PWO  in  visualising  his  response  procedures.  It  is  postulated 
that  this  facility  would  be  very  useful  at  the  stage  before  a  battle  when  details  about  the  enemy's 
capabilities  are  becoming  more  specific  and  the  PWO  is  trying  to  tune  his  resources  and  response 
procedures  accordingly.  A  contract  to  explore  and  develop  a  prototype  situation  assessment 
module  is  planned  for  next  year.  Future  work  at  ARE  involves  us  in  a  collaborative  programme  with 
the  US  Government  which  aims  to  investigate,  by  means  of  prototype  development  and 
observational  studies,  decision  making  in  the  areas  of  situation  assessment  and  resource 
allocation. 

Concluding  Remarks. 

What  then  are  the  issues  in  reactive  resource  allocation?  Basically  I  believe  that  reactive 
resource  allocation  can  be  automated  and  is  a  more  straightforward  problem  than  initially 
conceived.  It  is,  after  all,  more  amenable  to  validation  in  that  it  produces  a  defined  output.  This 
output  can  be  evaluated  and  compared  with  human  performance  both  for  its  effectiveness  in 
countering  the  threat  and  tor  its  speed  of  response.  A  spin-off  from  the  implementation  of  a 
resource  allocation  prototype  may  be  its  value  as  a  training  aid,  enabling  experiential  learning  and 
student  paced  development  of  expertise  at  the  same  time  as  the  development  ol  trust  and 
confidence  in  the  system. 

The  real  problem  lies  in  the  area  of  situation  assessment  where  human  expertise  comes  to 
the  fore  We  do  not  have  a  good  understanding  of  this  area.  If  Klein’s  model  is  valid,  then 
assessment  of  the  situation  would  seem  to  involve  human  recognitional  processes  which  are  not 
conscious  or  open  to  introspection.  Developments  in  connectionist  architectures  or  neural  nets 
seem  to  offer  a  way  forward  in  other  recognitional  domains  like  pattern  or  voice  recognition: 
perhaps  this  is  the  technology  required  for  situation  assessment.  In  the  meantime,  however,  I 
believe  that  experimental  investigations  of  the  situation  assessment  and  resource  allocation  tasks 
using  human  experts  teamed  with  partial  decision  support  is  the  best  way  forward. 
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1 .  BACKGROUND 

The  use  of  the  electronic  crew  in  rotary  wing  applications  is 
being  explored  in  several  U.S.  Army  laboratories.  Examples  of 
these  development  activities  include  digital  map  display 
systems,  day/night  all-weather  sensor  system,  integrated 
commun l ca t i on  systems,  and  automatic  target  acquisition  and 
recognition  systems.  Those  of  us  in  the  human  engineering 
crew  station  design  community  are  focusing  our  research  energy 
on  how  to  integrate  the  electronic  crew  capabilities  with  the 
human  crew. 

The  U.S.  Army  Human  Engineering  Laboratory  has  had  a  program 
in  place  for  examining  the  implication  of  automation  in  the 
cockpit.  A  specific  Army  aviation  mission  was  considered  for 
developing  this  program.  The  mission  was  helicopter  air-to- 
air  combat.  The  program  is  entitled  the  Human  Engineering 
Laboratory  Counter-air  Program  (HELCAP) .  It  addresses  the 
command  and  control  soldier  interface  issues  from  the  cockpit 
to  the  aviation  tactical  operations  center  (TOC) .  This  paper 
presents  a  review  of  the  program,  the  automation  Issues  being 
addressed,  and  the  progress  to  date. 

2.  DISCUSSION 

In  HELCAP,  the  focus  is  to  establish  the  human-machine 
interface  criteria  whereby  Army  air  defense  forces  can 
collaborate  with  Army  aviation  units.  The  general  concept  is 
to  examine  the  soldier  interfaces  at  four  critical  nodes  of 
counter-air  operations:  the  aviation  tactical  operations 

center,  the  helicopter  air-to-air  cockpit,  the  air  defense 
tactical  operations  center,  and  the  air  defense  fire  unit. 
Embedded  in  this  concept  is  the  fact  that  the  Army  aviation 
community  will  be  using  the  air  defense  ground-based  sensors 
that  form  the  backbone  of  the  forward  area  air  defense  (FAAD) 
system.  It  is  essential  to  pass  along  time-critical 
Information  in  an  expeditious  manner.  In  the  HELCAP  program, 
we  anticipate  examining  the  potential  for  employing  cockpit 
and  TOC  automation  toward  successful  mission  accomplishment. 
The  products  will  be  design  guidelines  for  designing 
control /display  interfaces  that  exploit  artificial 
intelligence  technology  in  enhancing  situation  awareness  and 
command  and  control  interfaces. 

3.  COUNTER-AIR  COCKPIT 
3.1  Counter-air  Display 

A  required  attribute  of  a  counter-air  display  is  the  need  to 
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provide  critical  command  and  control  information  to  the  p.lot 
in  a  manner  that  makes  the  information  readily  usable. 
Laboratory  research  was  used  to  develop  a  counter-air  display 
concept  to  meet  this  requirement.  Standardized  symbology 
provides  a  ready  source  of  information  about  fixed  and  rotary 
wing  aircraft  which  are  identified  as  hostile,  friendly,  or 
unknown.  In  addition,  target  location  is  represented  In  a 
planned  position  format.  Location,  velocity,  direction  and 
bearing  of  the  Identified  aircraft  from  the  location  of  the 
counter-air  helicopter  is  also  provided.  Through  hooking  a 
specific  target,  the  counter-air  helicopter  can  amplify  the 
information  about  any  single  or  group  of  multiple  targets 
Logic  can  be  built  into  the  display  which  will  provide  terrain 
profile  data  along  with  1 l ne - o f -s 1 gh t  information  so  that  the 
counter-air  helicopter  pilot  can  either  choose  his  point  of 
engagement  or  evade  any  nearby  threats.  Though  not  yet  in  the 
concept  display,  it  should  contain  other  forms  of  information 
to  facilitate  the  helicopter  counter-air  effectiveness.  For 
example,  battlefield  intelligence  indicating  the  location  of 
hostile  anti-aircraft  fire  units  would  enhance  battlefield 
survivability  and  locations  of  rearm  and  refuel  points  with 
preplanned  minimum  threat  routes  to  their  location  would 
increase  time  on  target. 

The  sizing  of  the  display  has  been  the  subject  of  considerable 
study,  analysis  and  experimentation.  The  parameters  of 
consideration  relative  to  size  were: 

Geographic  areas  of  coverage 
Symbol  size 
Symbol  obscuration 
Symbol  movement  resolution 
Symbol  update  times 

The  tradeoff  between  area  of  coverage/display  size/symbol 
resolution  resulted  in  concepts  for  using  displays  as  small  as 
three  inches  for  the  counter-air  application.  This  display 
size  was  considered  to  accommodate  an  electronic  display 
already  in  the  Army  inventory.  Interactive  software  permitted 
a  display  of  this  size  to  furnish  the  pilot  with  quality 
counter-air  information  and  enough  situation  awareness  needed 
to  conduct  counter-air  operations. 

3.2  Electronic  Map  Display 

The  vital  function  of  a  map  display  system  is  to  assist  the 
air  crew  in  maintaining  situational  awareness.  In  addition  to 
geographical  information,  it  should  also  provide  tactical 
information  and  logistic  information  all  of  which  should  be 
presented  in  an  integrated  form.  The  air  crew  needs  to  have 
the  system  Indicate  the  best  route  of  flight  to  avoid 
obstacles,  maintain  nap - o f - the  -  ear t h  profiles  and  engage  or 
avoid  enemy  targets  as  circumstances  dictate.  Planning  aids 
delineating  routes  of  flight  to  accommodate  mission  needs  will 
be  essential  to  minimize  crew  size  and  maximize  mission 
success .  Research  is  in  progress  at  the  Human  Engineering 
Laboratory  to  address  the  mission  planning  station  and  map 
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display  characteristics  which  provide  the  best  user 
interactions . 

3.3  Expert  Communicator 

The  flight  regime  of  Army  helicopters  is  very  hazardous. 

Flight  very  close  to  the  ground,  close  to  both  enemy  ground 
and  air  elements  requires  a  ready  means  of  communicating  with 
the  appropriate  command  channels.  All  radio  equipment  should 
be  integrated  into  a  single  system.  The  channel  and  security 
selections  should  be  pre-programmed  to  accommodate  the  planned 
mission  profile.  This  will  ensure  that  the  crew  can 
efficiently  communicate  with  the  critical  command  components 
when  required.  However,  situational  changes  on  the 
battlefield  make  it  imperative  that  these  automated 
commun i cat i on  links  be  flexible  enough  to  be  rapidly  changed. 
Concepts  of  commun i ca t i on  systems  with  these  attributes  will 
be  explored  in  future  research  by  the  Human  Engineering 
Laboratory 

3.4  Subsystem  Monitor 

This  subsystem  will  act  as  an  electronic  copilot.  It  will 
present  to  the  pilot  a  summary  status  of  all  critical  on-board 
systems  (i.e.,  hydraulic,  electrical,  environmental,  power 
plant,  etc.)  .  The  electronic  copilot  must  Integrate  the 
various  bits  of  system  information  and  provide  corrective 
options  to  the  pilot  in  case  of  system  emergencies. 

Minimizing  work  load  in  times  of  system  failures  is  essential 
to  mission  success . 

HELCAP  analysis  and  research  in  this  area  has  developed  a 
display  concept  that  alerts  the  pilot  on  a  'by  exception' 
basis.  In  this  concept ,  key  parameters  such  as  percent  torque 
and  fuel  time  to  go  will  be  displayed  continuously  on  the 
helmet  mounted  display  (HMD) .  A  dedicated  area  of  the  HMD 
will  be  available  to  provide  systems  alert  information  to  the 
crew.  A  logic  scheme  has  been  developed  to  provide  the  crew 
with  immediate  information  on  out-of-tolerance  systems 
conditions.  Redundant  synthesized  voice  commands  will  be 
available  along  with  information  on  the  mul t i - f unct i on  visual 
display. 

3.5  Sensor  Suites 

The  air-to-air  combat  mission  for  helicopters  necessitates  the 
capability  of  conducting  both  day  and  night  operations. 
Therefore,  sensor  systems  Including  both  imaging  and  non¬ 
imaging  will  be  required.  The  fusion  of  the  sensor  data  and 
the  presentation  of  that  data  on  minimum  display  surface  area 
is  essential.  Unique  display  concepts  for  implementing  fused 
images  must  be  employed.  One  concept  display  under 
development  allows  the  portrayal  of  both  radar  and  forward- 
looking  infrared  Imagery  on  a  single  display  surface.  This 
concept  will  enhance  crew  interaction  and  at  the  same  time 

save  valuable  panel  apace. 


The  use  of  computer  capabilities  for  the  processing  of  target 
images  through  automatic  target  recognition  systems  will  be 
essentials  of  the  automated  cockpit.  The  long  stand-off 
ranges  and  the  limited  target  cross-section  will  make  it 
virtually  impossible  to  attain  a  visual  identification  of 
potential  targets.  The  target  acquisition  system  will  have  to 
provide  this  capability.  Present  research  addresses  the 
methods  through  which  targeting  information  can  be  readily 
assimilated  by  the  crew.  These  research  areas  include  the 
effects  of  clutter  and  how  to  restore  target  images  so  they 
can  be  readily  detected  and  recognized,  the  effects  of 
chromoticity  on  target  detection  and  the  methodology  for 
determining  the  functions  that  can  best  be  performed  by  the 
crew  and  those  that  can  best  be  performed  by  the  ATR. 

3.6  Counter-air  Cockpit  Development  Summary 

The  automated  cockpit  components  described  above  have  been 
integrated  into  the  Human  Engineering  Laboratory  HELCAP 
simulator.  This  cockpit  simulation  integrates  the  data 
developed  through  experimentation  that  identified  the  number 
of  displays,  the  information  on  each  and  the  potential  methods 
of  Interacting  with  these  displays.  The  simulator 
incorporates  four  panel  mounted  electronic  displays,  a  helmet- 
mounted  display,  voice  interactive  systems  and  touch  sensitive 
displays.  These  concepts  will  be  demonstrated  in  an 
integrated  demonstration  in  the  third  quarter  of  1991. 

4  TACTICAL  OPERATIONS  CENTER  (TOC) 

The  HELCAP  program  has  also  investigated  the  essential 
charac ter i a t l cs  of  the  aviation  TOC.  The  objective  of  these 
investigations  was  to  ascertain  the  types  of  information  that 
must  go  through  the  TOC  and  formats  which  make  it  most  easy 
for  the  commander  to  use.  Because  of  the  flow  of  the  air 
battle,  the  commander  must  be  capable  of  issuing  unambiguous 
orders  to  counterair  helicopters  with  very  little  preparation 
time.  Minimizing  the  staffing  of  the  TOC  is  also  important  in 
these  times  of  minimum  personnel  staffing.  Here,  too,  data 
must  be  Integrated  into  a  ready-to-use  form  so  the  field 
commander  can  be  given  a  ready  grasp  of  his  air  picture  and 
assets.  The  research  in  this  area  began  with  surveys  of  TOCs 
in  operation  during  training  maneuvers.  These  surveys 
resulted  in  determining  the  types  of  information  that  flow 
into  and  out  of  TOCs  and  how  to  code  this  information.  From 
this  start,  the  research  is  continuing  into  the  development  of 
user-friendly  softwa’  procedures  for  utilizing  the  automated 
TOC  . 

5  SUMMARY 

The  HELCAP  program  has  been  in  progress  for  almost  3  years. 
Simulated  tactical  operations  centers  are  being  integrated 
with  a  simulated  futuristic  air-to-air  helicopter  cockpit. 
Similarly,  a  state-of-the-art  air  defense  fire  unit  display  is 
being  formulated.  These  components  will  use  a  simulated  air 
battle  scenario  to  provide  realistic  stimuli  for  assessing  the 
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merits  of  the  initial  designs.  Present  part  task  data  bases 
have  been  collected  about  various  modalities  to  interact  with 
the  electronic  copilot.  These  have  Included  eye  gaze 
pointing,  using  electroencephal ogram  information,  touch 
screens,  bezel  switches,  and  voice  recognition  systems.  Our 
schedule  calls  for  an  integrated  demonstration  of  these 
so  Id i er - machi ne  concepts  in  the  third  quarter  of  1991.  This 
demonstration  will  be  the  initial  phases  of  an  interactive 
process  for  enhancing  the  effectiveness  of  automation  in 
counter-air  operations. 
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Microcomputer  Centre,  The  University, 
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1  INTRODUCTION 

The  objective  of  this  paper  is  to  highlight  the  research  being  undertaken  at  Dundee  University  in 
collaboration  with  GEC  AVIONICS  in  addressing  human-machine  interaction  problems.  The  research 
will  compare  and  contrast  the  needs  and  solutions  for  the  pilot  of  an  aircraft  in  all  conditions  (including 
emergencies)  and  the  physically  and/or  cognitively  impaired  person  interacting  with  a  personal 
workstation  of  the  future.  The  ECHO  project  is  a  co-ordinated  programme  of  research  between  Dundee 
University  and  GEC  Avionics  and  results  from  a  concept  proposed  by  Newell  in  a  paper  [1]  which  argues 
for  the  advantages  of  a  co-ordinated  programme  of  research  into  the  problems  of  both  ’ordinary’  human 
beings  in  ’extra-ordinary’  situations  and  ’extra-ordinary’  human  beings  (such  as  the  disabled)  in 
’ordinary’  situations. 

The  remainder  of  this  paper  is  split  up  into  five  main  sections.  The  first  of  these  gives  an  overview  of  the 
research  being  carried  out  by  the  ECHO  project.  This  is  then  followed  by  a  section  which  proposes  the 
view  that  all  human  beings  can  be  considered  disabled  to  some  extent  in  relation  to  the  environment  they 
find  themselves  in.  Section  four  discusses  and  compares  the  interface  requirements  needed  to  be 
considered  when  designing  for  disabled  and  able-bodied  applications,  while  user  modelling  and  expert 
system  techniques  are  addressed  in  section  five.  Section  six  sets  out  the  paper’s  conclusions. 

2  ECHO  PROJECT 

The  ECHO  project  is  concerned  with  addressing  the  problems  of  human-machine  interaction  where  the 
characteristics  of  the  user  and  the  environment  in  which  the  interface  is  situated  can  change  dramatically 
and  rapidly  over  time.  The  ECHO  project  will  focus  upon  the  following  three  issues  :- 

1 .  Increasing  and  making  more  efficient  use  of  the  bandwidth  between  the  user  and  the  machine. 

2.  Making  a  system  more  adaptive  and  personalized  to  the  user. 

3.  Provisions  for  the  system  to  be  able  to  handle  crisis  situations  without  calling  upon  extra-orainary 
human  effort  and  hence  error. 

In  the  first  instance  the  research  will  investigate  two  very  dissimilar  application  areas,  but  ones  which 
have  very  similar  design  requirements.  Ultimately,  the  systems  developed  during  this  project  will  be 
appropriate  for  incorporation  into  applications  other  than  the  two  specific  areas  which  the  project  is 
looking  at  initially. 

Demonstrators  will  be  developed  based  on  the  provision  of  multimode  presentation  of  information  and 
control  of  the  system,  plus  intelligent  knowledge  based  prediction  of  the  requirements  of  both  the  operator 
and  the  task.  i.e.  the  aeroplane  and  the  workstation  for  the  disabled  respectively.  This  work  will  be 
developed  using  the  concept  of  a  synthesised  cockpit  view  and  the  use  of  intelligent  knowledge  base 
system  technology  for  display  management  being  developed  by  GEC  Avionics;  and  a  similar  but  parallel 
coocept  of  adaptive  and  predictive  interface  design  and  the  use  of  discourse  analysis  and  dialogue 
structures  for  prediction,  which  is  being  developed  at  Dundee  University[2]. 

3  TEMPORARY  AND  PERMANENT  DISABILITY 

One  view  held  within  the  field  of  rehabilitation  engineering  is  that  human  beings  ate  all  disabled  by  their 
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environments  to  varying  degrees.  This  is  true  of  able-bodied  people  as  of  those  who  are  classified  as 
disabled.  The  parallels  between  disabled  people  and  the  able-bodied  operating  in  a  stressful  environment, 
such  as  the  pilot,  is  much  closer  than  it  may  appear.  Table  1  illustrates  some  examples  given  by  Newell 
and  Caims(3], 


ENVIRONMENT  EFFECT  OF  ENVIRONMENT 

TEMPORARY 

communication  over  hearing  impairment 

distance  which  is  too  large: 

noise; 


inadequate  illumination;  visual  impairment  TABLE  1  -  Disabling  Environments 

fog; 

undersea; 


protective  clothing;  motor  impairment 

cold; 

fatigue; 


stress:  cognitive  impairment 

fatigue: 


distance  too  great:  impairment  of  mobility 

rough  terrain: 


Some,  if  not  all,  of  these  environments  and  tbeir  effects  have  been  documented  in  avionics  literature 
14.5,6,7,8,9,10].  In  particular,  the  effects  of  automation  in  the  cockpit  and  lack  of  situational  awareness 
have  received  much  attention  with  respect  to  their  individual  effects  on  pilots’  workload  and  performance. 
The  cognitive  demands  placed  on  a  pilot  due  to  the  increase  in  workload/information  ovedoad  are 
probably  the  most  common  form  of  impairment  faced  by  today’s  pilot  [10,1 1,12,13,14]. 

AU  human  beings  are  limited  in  the  amount  of  information  that  they  can  cope  with  at  any  one  time.  If 
they  are  presented  with  an  amount  of  information  which  exceeds  this  limit  (whether  it  be  in  visual, 
auditory  or  tactile  format)  then  the  probable  outcome  of  the  situation  will  be  that  the  person  will  be  unable 
to  perform  in  a  satisfactory  manner  in  order  to  control  the  situation  they  find  themselves  in. 

Wiener(6]  has  stated  that  automation  in  the  cockpit  has  not  eliminated  human  error,  but  has  shifted  the 
nature  of  errors.  That  is,  as  systems  have  become  more  automatic,  the  role  of  the  human  being  has 
become  less  physically  active  and  more  cognitive.  In  relieving  the  pilot  of  physical  (manual)  movements, 
automation  has  subsequently  marked  an  increase  in  the  pilot’s  cognitive  workload.  Hence  the  original 
aims  of  automation,  trying  to  reduce  crew  workload  and  eliminate  human  error,  (which  could  be 
considered  as  trying  to  decrease  (he  impairments  of  the  crew)  have  not  in  fact  been  met  Reducing 
physical  (manual)  procedures  has  resulted  in  increased  cognitive  workload  with  the  consequence  that 
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errors  have  now  presented  themselves  in  different  ways. 

Also,  in  modem  military  aircraft,  information  is  sensed  in  highly  sophisticated  ways  and  combined  by  the 
aircraft’s  computers  to  be  presented  on  electronic  displays.  These  displays  are  generally  well  engineered 
and  reliable  but  in  practice  seem  to  encourage  the  pilot  into  creating  his  own  mental  model  of  his 
situation,  based  on  the  electronic  display  symbology  alone,  and  ignoring  other  important  readings  being 
presented  to  him  from  his  instruments.  This  can  subsequently  lead  to  pilot  disorientation  and  exemplifies 
the  impairment  of  cognitive  processing[4,12]. 

4  INTERFACE  REQUIREMENTS 

The  previous  section  illustrated  how  pilots  suffer  from  similar  handicaps  to  those  that  disabled  people  do. 
It  is  thus  illuminating  to  consider  how  interface  requirements  faced  by  designers  of  equipment  for  the 
disabled  compare  to  those  for  the  ordinary  population.  The  ways  in  which  rehabilitation  engineers  have 
increased  the  bandwidth  between  a  human  and  computer  can  then  be  considered  with  a  view  to  examining 
new  potential  and  mote  mainstream  situations.  In  designing  for  the  disabled,  one  is  forced  to  consider 
wider  aspects  of  the  interface  problem  in  respect  to  the  real  needs  and  wants  of  the  human.  The  human 
interface  problems  faced  are  similar  to,  but  more  severe  than  those  faced  by  the  designers  of  equipment 
for  the  ’ordinary’  population  and  their  solutions  can  often  be  mote  ’user  friendly’  than  those  produced  by 
groups  without  this  particular  perspective  [1]. 

Speech  recognition  systems,  which  ate  used  as  an  alternative  input  device,  offer  benefits  to  the  disabled 
and  for  those  whose  visual  attention  is  otherwise  engaged  (e.g.  pilots).  In  both  of  the  above  cases  the 
interface  needs  to  be  able  to  o-  with  the  variability  in  the  users  voice.  In  military  applications,  speech 
recognition  systems  are  use.  to  control  the  flight  management  system  and  its  associated  displays. 
Advance  models  of  s'  jo  stems  require  to  cope  with  the  human  speaker’s  variability  that  results  from 
changing  environmental  conditions  typically  experienced  in  military  fast  jets.  These  systems  require  to 
pass  severe  acceptance  levels  -  similar  to  the  more  severe  design  constraints  which  need  to  be  considered 
when  designing  for  the  disabled.  In  the  case  of  the  pilot,  speaker  variability  is  caused  by  effects  such  as 
noise,  acceleration,  stress  and  head  position[15].  Likewise,  the  speech  variability  of  the  disabled  can  be 
due  to  ^  articular  speech  impairments  or  due  to  the  effects  of  the  distortion  of  the  persons  vocal  tract  due 
to  uncontrollable  upper  body  movement 

4  1  Bandwidth 

The  able-bodied  person  in  a  high  workload  environment  and  the  disabled  share  a  common  problem  -  the 
bandwidth  of  the  channel  which  is  available  in  both  directions  (input  and  output)  is  not  sufficient  for  them 
to  effectively  and  efficiently  complete  their  task.  One  of  the  aims  of  the  ECHO  project  is  to  investigate 
how  the  bandwidth  between  the  computer  and  the  user  can  be  increased.  This  bandwidth  is  subject  to 
constraints.  In  a  specific  environment,  human  beings  have  a  limited  ability  to  cope  with  a  particular 
amount  of  immediate  information  which  is  either  presented  to  them  or  which  they  have  to  operate  on, 
whether  that  information  is  presented  to  them  in  a  visual,  auditory  or  tactile  format  A  tactile  display  used 
by  a  blind  person  to  read  text  and  the  head  up  display  used  by  pilots  are  examples  of  devices  which  are 
used  to  present  a  limited  amount  of  information  to  the  user,  in  relation  to  their  limited  ability  to  process  it. 

Current  user-computer  dialogues  tend  to  be  one-sided  with  the  bandwidth  from  the  computer  to  the  user 
(e.g.  VDU  output)  far  greater  than  that  from  the  user  to  the  computer  (e.g.  keyboard  input).  This 
imbalance  can  restrict  the  effectiveness  of  the  overall  system.  Figure  1(a)  illustrates  the  narrow  input 
bandwidth  between  the  user  and  computer.  Research  into  human-computer  interaction  technology  has 
done  a  lot  to  improve  information  transfer  with  respect  to  producing  alternative  input  devices  and 
incorporating  techniques  to  filter  out  errors.  However,  not  much  has  been  done  to  increase  the  quantity  of 
information  transferred  from  the  user  to  the  computer  system.  In  order  to  increase  this  bandwidth  more 
information  requires  to  be  captured  from  the  user.  In  principle  this  could  be  done  by  directly  sensing  the 
user’s  thoughts  or  by  increasing  the  number  of  input  channels.  Out  of  the  above  techniques,  the  second  of 
these  seems  more  immediately  attainable  today.  This  could  be  done  by  capturing  gestural,  vocal  and 
other  physiological  features.  Sbein  at  al  [16]  illustrate  this  concept  in  figure  1(b).  Similarly,  increasing 
the  output  bandwidth  needs  to  be  investigated.  Most  current  interfaces  only  provide  output  in  a  visual 
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format.  Move  work  should  be  done  on  investigating  alternative  (non-visual)  sensory  modalities.  It  is 
believed  that  systems  incorporating  higher  levels  of  man-monitoring  such  as  this  will  result  in  systems 
which  will  produce  better  user  models  on  which  to  infer  the  operators  intentions  [17]. 

5  USER  MODELLING 

In  conjunction  with  investigating  the  increased  bandwidth  in  human-machine  interaction,  the  ECHO 
project  will  also  address  the  subject  of  user  modelling.  That  is,  how  can  an  intelligent  knowledge  based 
system  be  utilized  to  create  a  computer  system  which  is  more  adaptive  and  personalised  to  a  particular 
user.  For  such  a  system  to  be  efficient,  it  must  be  capable  of  remodelling  dynamically  in  a  non-obtrusive 
way  to  accomodate  the  user  with  whom  it  is  interacting  [18].  The  result  of  this  adaptive  user  modelling 
will  lead  to  improved  man-machine  communication,  assist  the  user  in  the  correct,  effective  and  efficient 
use  of  the  system,  thereby  enhancing  the  user’s  knowledge  on  how  to  use  the  system. 

As  a  consequence  of  our  collaboration  with  GEC  Avionics,  we  will  exploit  their  use  of  intelligent 
knowledge  based  systems  for  display  management  in  assisting  the  pilot  of  a  single-seat,  high  performance 
aircraft  at  times  of  exceptionally  high  unplanned  workload.  In  parallel  to  the  pilot  in  the  above  situation, 
it  is  believed  that  a  computer  based  system  developed  for  the  disabled,  specifically  to  cater  for  groups  of 
people  with  varying  degrees  of  disabilities,  should  be  capable  of  being  able  to  handle  imprecise 
information,  choose  the  most  promising  approach  from  a  number  of  strategies,  perform  a  measure  of 
logical  reasoning,  explain  its  conclusions  and  offer  appropriate  advice.  The  implementation  of  such  an 
intelligent  knowledge  based  system  will  use  a  plan  recognition  mechanism  which  is  seen  by  us  as 
involving  three  stages  :  monitoring,  inferendng  and  prediction. 

-  Monitoring  is  defined  as  the  process  of  collecting  data  from  a  user.  Data  which  is  collected  from  input 
devices  (e.g.  keyboard,  joystick)  in  order  to  dhecdy  control  a  specific  task  is  defined  as  direct  monitoring. 
Data  gathered  from  the  user  by  sensor/tracker  devices  which  provides  information  on  the  type  of 
behaviour  the  user  is  exhibiting  is  defined  as  attention  monitoring. 

-  Inferendng  is  defined  as  the  act  of  drawing  conclusions  on  data  which  has  been  gathered  from  the 
monitoring  stage.  (These  conclusions  may  not  necessarily  be  valid).  Information  is  also  extracted  from 
relevant  knowledge  bases  into  this  process.  Inferencing  can  be  divided  into  direct  inferendng  and 
attention  inferencing.  Direct  inferencing  utilises  data  collected  from  the  previous  direct  monitoring  stage. 
Likewise  attention  inferencing  uses  data  gathered  from  the  previous  attention  monitoring  stage  on  which 
to  base  condusions. 

-  Prediction  i3  defined  as  attempting  to  guess  what  to  do  next  based  on  the  previous  inferencing  and 
monitoring  stages.  It  is  thought  of  as  being  the  output  from  the  inferencing  process  and  is  subsequently 
used  as  feedback  into  the  monitoring  step,  thereby  enhancing  the  plan  recognition  cycle. 

The  ECHO  project  will  incorporate  the  concepts  of  existing  projects[2]  at  Dundee  University  into  the 
monitoring,  inferendng  and  prediction  stages  of  the  plan  recognition  mechanism.  Examples  of  these 
include  :- 

-  predictive  and  adaptive  systems  which  give  significant  keysaving  when  entering  text  into  computer 
systems 

-  conversational  systems  for  the  speech  impaired  based  on  a  computer  model  of  the  dialogue  structures  of 
human  conversation 

-  automatic  analysis  of  gestures  made  by  those  with  motoric  dysfunction 

-  applications  of  relational  database  technology  and  semantic  net  hypertext  structures  for  navigating 
through  spoken  language 

-  the  use  of  computer  systems  to  assist  those  with  language  dysfunctions. 

Also  incorporated  in  this  intelligent  knowledge  based  system  (KBS)  will  be  some  form  of  error  tolerant 
interface,  as  described  by  Hollnagel  [19],  which  will  enable  the  system  to  function  so  that  it  takes  in  most 
of  the  inevitable  variations  in  human  capadty.  Such  an  error  monitor  can  provide  important  support  for 
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overcoming  users  limitations(20].  Error  identification  detects  irregularities  between  expected  and 
observed  behaviour  and  has  useful  implications  in  the  design  of  an  intelligent  system,  such  that 
distinctions  can  be  made  between  an  inappropriate  intention  and  an  incorrect  execution  of  actions[21]. 
When  errors  occur  due  to  a  user’s  misunderstanding,  it  is  likely  that  the  user  will  require  some  form  of 
explanation  before  accepting  the  conclusion  that  their  choice  was  wrong. 

6  CONCLUSION 

The  main  aim  of  the  ECHO  research  is  the  development  of  a  workstation  which  incorporates  an  increased 
bandwidth  and  some  form  of  plan  recognition  mechanism.  In  comparing  the  human  computer  interface 
needs  of  a  pilot  to  those  of  a  disabled  user  we  are  presenting  the  hypothesis  that  all  human  beings  can  be 
considered  disabled  to  some  extent  depending  on  the  environment  they  find  themselves  in.  Although  the 
ECHO  research  is  only  looking  at  comparing  two  applications  (the  pilot  and  the  disabled)  this  line  of 
research  could  equally  be  applied  to  other  applications  whether  they  be  military  or  commercial.  The  aim 
of  forming  a  more  co-ordinated  programme  of  research  between  existing  research  groups  to  raise  the  issue 
of  parallels  between  these  two  fields  of  research  will  lead  to  fruitful  discussions  and  cross-fertilisation  of 
ideas.  Investigating  in  more  detail  the  real  needs  of  people  will  lead  to  better  design  and  can  result  in 
reduced  cost  to  a  project  in  the  long  rua 

At  present  the  ECHO  project  is  in  its  early  stages.  Data  is  being  collected  on  input  and  output  devices 
which  are  currently  available  and  can  be  used  by  the  disabled.  A  basic  architecture  for  the  computer 
workstation  demonstrator  is  being  specified.  This  outlines  how  the  ECHO  project  sees  the  workstation 
being  developed  in  its  early  stages.  Investigations  into  the  application  of  intelligent  knowledge  based 
systems  are  dso  still  in  their  infancy.  It  is  hoped  that  we  can  obtain  relevant  guidelines  and  exploit 
techniques  from  a  workshop  such  as  this. 
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Summary 

The  move  towards  more  technologically  complex  mission  systems,  for  handling  increased 
mission  sophistication,  coupled  with  limits  on  available  manpower  resources,  is  leading  to 
increased  crew  workload  and  more  lengthy  training  of  operators  for  many  existing  and  future 
aircraft.  RAE  has  a  research  programme  to  investigate  how  expert  systems  technology  can  be 
exploited  to  relieve  this  problem  by  enabling  the  development  of  decision  support  aids  to  reduce 
crew  workload  and  improve  operator  performance.  It  examines  the  technology  and  its 
capabilities,  and  builds  specific  application  projects  to  demonstrate  the  benefits  of  the 
technology.  One  aspect  of  this  programme  is  the  development  of  a  means  for  building  validated 
expert  systems  that  can  be  reliably  deployed. 

Expert  systems  have  special  properties  which  complicate  the  validation  process,  such  as  their 
capability  to  express  complex  decision-making  processes.  They  require  all  participants  in 
system  development  to  have  a  shared  basis  on  which  to  set  and  assess  acceptable  standards. 
The  VORTEX  project,  commissioned  by  RAE,  aims  to  develop  this  basis  from  actual  experience 
rather  than  abstract  thinking.  It  is  divided  into  two  parallel  strands:  an  application  strand  which 
builds  a  robust  expert  system  demonstrator  called  the  Sensor  Advisor,  and  a  methodology 
strand  which  captures  the  experiences  gained  from  building  the  demonstrator  and  consolidates 
them  in  a  validation-oriented  expert  systems  methodology. 

An  important  validation  issue  is  operator  acceptance.  It  was  addressed  in  VORTEX  through 
careful  expert  system  design,  and  by  involving  designated  domain  experts  throughout  the 
demonstrator’s  life-cycle. 


1  Introduction 

In  1986  Logica  undertook  a  study  on  behalf  of  RAE  to  investigate  the  validation  of  real-time 
knowledge-based  systems  [1].  The  Study  considered  the  extent  to  which  existing  specification 
and  validation  methods  can  be  applied  to  expert  systems  and  outlined  an  approach  to  expert- 
system  validation.  It  also  recommended  that  the  next  step  should  be  to  monitor  the  development 
of  a  laboratory-based  demonstrator  which  applied  the  methodology.  As  a  result  RAE  initiated 
the  first  phase  of  the  VORTEX  project  in  1988.  The  project  was  divided  into  two  parallel  and 
complementary  strands  of  work:  a  methodology  strand  and  a  demonstrator  strand.  The 
demonstrator  strand  developed  a  real-time  expert  system  as  a  means  of  refining  and  testing  the 
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proposed  methodology.  Through  this  strand,  actual  experience  of  the  early  stages  of  a  full 
expert  system  life-cycle  and  insight  into  the  validation  issues  relevant  to  later  stages  of  the  life- 
cycle  were  gained.  These  results  were  analysed  in  the  methodology  strand  and  consolidated  in  a 
Final  Report  (2). 

The  demonstrator  strand  of  the  VORTEX  project  consisted  of  four  well  defined  phases: 
application  selection,  demonstrator  definition,  demonstrator  development,  demonstrator 
delivery  and  evaluation.  Application  selection  identified  several  candidates,  and  specified 
selection  criteria  to  choose  one  as  the  subject  of  the  definition  phase.  Demonstrator  definition 
built  a  small  feasibility  prototype  that  helped  determine  whether  this  application  would  make  a 
suitable  candidate  for  a  demonstrator,  and  also  enabled  RAE,  domain  experts  and  the 
development  team  to  gain  a  clearer  idea  of  the  demonstrator’s  intended  functionality  and 
implementation  environment.  Demonstrator  development  involved  the  design,  implementation 
and  testing  of  the  demonstrator  software.  Demonstrator  delivery  and  evaluation  installed  the 
demonstrator  software  on  RAE’s  Symbolics  workstation  at  Famborough  and  conducted  several 
validation  experiments  that  aimed  to  assess  the  usefulness  of  the  demonstrator’s  output,  the 
validity  of  its  knowledge  base  and  its  future  requirements. 

The  methodology  strand  analysed  the  work  undertaken  in  each  phase  of  the  application  strand 
and  identified  the  strengths  and  weaknesses  of  our  approach  to  building  the  expert  system 
demonstrator.  Two  important  aspects  of  this  work  were  the  development  of  verification  and 
validation  support  tools,  and  the  validation  experiments  undertaken  as  part  of  the  delivery  and 
concluding  validation  phase  of  the  application  strand.  The  support  tools  facilitate  inspection  and 
testing  of  the  knowledge  base.  The  validation  experiments  provided  an  insight  into  the  sorts  of 
procedure  that  could  be  employed  to  validate  an  expert  system,  and  determined  what  validation 
was  achievable  with  the  current  demonstrator.  They  also  prompted  further  knowledge 
acquisition,  demonstrating  the  synergy  that  exists  between  development  and  validation  in  expert 
systems. 


2  Vortex  demonstrator 

2.1  Application 

The  VORTEX  demonstrator  needed  to  be  both  a  plausible  application  for  improving  mission 
performance  and  sufficiendy  constrained  for  the  purposes  of  investigating  and  developing  the 
expert  system  methodology  proposed  by  the  Validation  Study.  It  consists  of  the  Sensor 
Advisor  and  its  Support  Environment.  The  Sensor  Advisor  is  the  software  that  demonstrates 
the  application  of  expert  systems  technology,  and  the  Support  Environment  is  the  software  that 
is  used  to  develop,  verify  and  validate  the  Sensor  Advisor. 

In  consultation  with  domain  experts,  RAE  chose  an  ASW  tactical  decision-aid  for  a  rotary-wing 
aircraft  as  the  application  area.  Crew  workload  can  vary  considerably  during  a  sortie".  For 
example,  workload  is  often  low  when  flying  to  a  barrier  and  excessive  when  prosecuting  a 
target.  The  demonstrator  helps  even  out  these  wide  variations  by  advising  the  Observer  on  the 
selection  and  deployment  of  sensors  for  the  detection,  tracking  and  prosecution  of  submarines. 
Sensor  selection  recommends  the  best  sensors  from  the  aircraft’s  sensor  suite  to  deploy  for  a 
particular  mission  scenario,  and  sensor  deployment  recommends  the  best  way  to  use  these 
sensors.  In  this  way.  Observers  are  relieved  of  some  straightforward  ASW  tasks,  thereby 
providing  extra  time  to  consider  more  important  tactical  decisions.  A  further  benefit  of  the 
expert  system  is  that  it  can  consistently  consider  all  relevant  information.  It  avoids  overlooked 
options  at  times  when  it  is  not  clear  what  actions  to  take,  such  as  loosing  contact  with  a  target, 
and  so  can  increase  the  performance  of  novice  or  average  Observers. 

2.2  Sensor  Advisor 

The  Sensor  Advisor’s  knowledge  base  is  expressed  in  ASW  specific  terms,  using  vocabulary 
and  structure  familiar  to  ASW  specialists.  This  is  important  for  validation.  Making  the 
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knowledge  base  more  aceessiblc  to  ASW  specialists  means  that  they  can  directly  validate  its 
contents.  The  knowledge  base  is  divided  into:  domain  knowledge  such  as  threat,  sensor  and 
weapon  data;  and  problem-solving  knowledge  such  as  ASW  tactics  and  their  application. 
Problem-solving  knowledge  is  represented  as  decisions  which  need  to  be  made  and  the  tasks 
which  make  them.  Tasks  are  typically  implemented  as  production  rules,  although  they  can  be 
algorithmic.  Together,  these  components  provide  a  depository  within  which  to  record  evolving 
ASW  tactics.  Because  ASW  specialists  can  easily  understand  the  language  used  to  express 
these  tactics,  the  knowledge  base  also  serves  as  the  basis  for  discussing  and  improving  them. 

The  tactical  expertise  represented  in  the  knowledge  base  considers  the  mission  brief,  sortie  data 
and  other  information  to  advise  the  Observer  on  which  sensors  to  use  and  how  to  use  them. 
For  sonobuoys,  it  specifies  the  buoy  type,  position,  separation  and  depth.  For  MAD,  radar  and 
ESM,  it  advices  when  and  how  to  use  them;  for  instance,  should  the  radar  be  used 
continuously  or  intermittently,  and  along  what  vector,  relative  to  threat  bearing,  should  MAD 
be  used.  A  concise  explanation  of  the  rationale  for  this  advice  is  also  given,  based  on  the  key 
decisions  made.  This  helps  build  the  confidence  that  Observers  have  in  the  Sensor  Advisor’s 
recommendations. 

Input  to  the  expert  system  is  provided  through  a  simulation  of  a  typical  avionic  input  device. 
There  is  also  a  separate  interface  used  to  control  a  demonstration  and  inspect  the  detailed 
reasoning  responsible  for  the  recommended  advice.  It  is  divided  into  a  control  and  trace 
window.  The  trace  window  would  not  be  present  on-board  the  aircraft,  but  might  exist  in  an 
operational  support  station.  Its  purpose  is  to  build  the  confidence  that  ASW  specialists  and 
developers  have  in  the  Sensor  Advisor,  by  providing  a  detailed  description  of  the  reasoning 
behind  the  Sensor  Advisor’s  advice.  The  control  window  provides  access  to  the  mission 
system.  It  lets  you  simulate  mission  system  events  such  as  sonobuoy  detections,  and  maintain  a 
clear  separation  between  Observer  and  mission  system  interaction.  This  enables  a  better 
appreciation  of  the  expected  level  of  interaction  between  the  Observer  and  the  Sensor  Advisor. 

The  Sensor  Advisor  copes  with  real-time  constraints  in  the  same  way  as  an  expert  Observer 
would.  Operators  can  interrupt  current  reasoning  and  input  unsolicited  information  such  as 
intelligence  on  threat  type.  The  Sensor  Advisor  will  then  modify  its  reasoning  in-line  with  this 
new  information.  Similarly,  asynchronous  mission  system  events  can  alter  the  Sensor 
Advisor’s  reasoning.  Advice  is  also  generated  within  time  limits  acceptable  to  the  operator. 
Domain  experts  identified  situations  where  response  times  were  critical  and  described  their 
problem-solving  approach  accordingly.  Thus  timing  constraints  are  expressed  implicitly  within 
the  problem-solving  knowledge.  Moreover,  in  some  cases  the  Sensor  Advisor  will  suppress 
user  interaction  to  increase  its  speed  of  response.  However,  enabling  the  user  to  take  part  in  the 
Sensor  Advisor’s  reasoning  process  is  a  significant  factor  in  gaining  operator  acceptance. 

2.3  Support  Environment 

An  important  part  of  the  demonstrator  is  the  Support  Environment.  This  environment  facilitates 
the  modification  and  validation  of  the  Sensor  Advisor’s  knowledge  base.  A  syntax-directed 
editor  enables  the  addition  and  modification  of  problem-solving  knowledge  without  the  need  to 
remember  the  exact  way  tasks  are  represented.  Verification  tools  are  used  to  check  a  task’s 
correctness  and  consistency  with  respect  to  the  rest  of  the  knowledge  base.  Validation  tools  are 
provided  to  assist  with  knowledge  base  inspection  and  testing.  They  are  used  to  view  the 
various  elements  and  inter-relationships  within  the  knowledge  base,  both  statically  and  at  run¬ 
time,  in  a  way  that  is  useful  to  ASW  specialists. 

This  support  environment  was  used  by  ASW  specialists  in  evaluating  the  Sensor  Advisor. 
They  agreed  that  it  was  an  important  and  useful  part  of  the  demonstrator,  which  was  essential 
for  the  validation,  acceptance  and  maintenance  of  the  Sensor  Advisor’s  knowledge  base,  litis 
view  is  consistent  with  the  Rome  Air  Development  Centre’s  work  on  a  Software  Life-Cycle 
Support  Environment  [3|  which  combine  development  tools  with  tools  to  assist  in  verification 
and  validation. 
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3  Managing  expert  system  development  for  acceptance 

Mackie  and  Wylie  |4|  provide  a  good  model  of  the  acceptance  process  which  suggests  the 
following  as  being  key  to  a  new  system  gaining  acceptance: 

•  Involve  operators  in  the  development  such  as  credible  experts  and  operator 
representatives.  Use  their  input  in  the  development  process  and  demonstrate  the  relative 
advantages,  operational  validity,  reliability  and  limitations  to  the  operators. 

•  Communicate  with  potential  operators  to  identify  critical  issues  such  as  desired  features, 
beliefs,  operational  need  r.nd  disocrr.inatc  information  to  show  that  operator  needs  have 
been  considered  and  the  benefits  can  be  described. 

•  Design  for  acceptance  with  general  design  criteria  such  as  operational  constraints,  clear 
concise  output,  quick  easy  input  and  application  specific  features. 

The  VORTEX  methodology  recognises  that  operators,  experts,  procurers  and  developers  must 
share  responsibility  for  validating  an  expert  system,  if  final  acceptance  is  to  be  achieved.  It 
advocates  a  life-cycle  in  which  the  validation  process  is  integrated  with  system  development. 
The  life-cycle  is  divided  into  phases  and  stages  which  produce  validated  products,  and  the  rest 
of  the  methodology  indicates  which  aspects  to  validate  at  each  point  and  how  validation  may  be 
accomplished. 

Validation  can  be  carried  out  only  against  a  statement  of  specification.  However,  a  trade-off 
exists  between  the  level  of  abstraction  at  which  the  specification  is  made  and  the  objectivity 
with  which  the  validation  process  can  be  carried  out.  For  expert  systems  it  is  very  hard  to 
produce  a  sufficiently  detailed  specification  prior  to  implementation.  This  is  particularly  so  for 
the  quality  of  output  generated  by  the  expert  system  and  the  range  of  circumstances  under 
which  this  effectiveness  of  operation  is  expected.  The  consequence  of  this  for  expert  system 
development  and  acceptance  is: 

•  It  is  necessary  to  operate  at  a  high  level  of  impact  on  operational  effectiveness.  The  whole 
system  cannot  be  specified  at  a  low  level  of  abstraction  and  be  subjected  to  strong 
objective  validation.  This  implies  a  layered  view  for  the  specification  of  expert  systems, 
that  evolves  as  development  proceeds. 

•  The  specification  is  more  evenly  distributed  across  the  development  life-cycle  than  is  the 
case  for  other  software  technologies.  This  implies  an  interactive  approach  to  expert 
system  validation  rather  than  the  traditional  “specify,  implement  and  test”. 

The  VORTEX  methodology  seeks  to  progressively  build  confidence  that  operator  requirements 
can  be  met,  while  minimizing  the  risk  that  the  system  will  operate  outside  limits  of  acceptable 
performance.  This  approach  compliments  the  NASA  Amcs-Dryden  methodology  which 
advocates  incremental  confidence  building  for  flight  and  mission-critical  software  1 5 1.  It  is, 
therefore,  essential  that  operators  and  their  representatives  be  involved  in  expert  system  life- 
cycle  from  the  start.  In  the  application  strand  of  VORTEX,  ASW  specialists  were  shown  how 
expert  systems  technology  could  be  applied  to  the  range  of  situations  faced  by  the  operator, 
operators  were  involved  in  the  choice  of  an  application  that  provides  valuable  support  that  is  not 
available  in  existing  mission  systems,  and  designated  domain  experts  regularly  reviewed  and 
updated  the  Sensor  Advisor. 


4  Expert  system  design  and  operator  acceptance 
4.1  Knowledge  representation 

Greatest  benefit  from  early  operator  involvement  is  achieved  when  the  knowledge 
representation  used  is  both  accessible  and  machine-executable.  For  the  Sensor  Advisor,  the 
expertise  used  to  generate  advice  on  ASW  tactics  is  programmed  in  terms  of:  what  decisions  are 
being  made  (such  as  whether  to  go  active  or  passive);  what  information  is  needed  to  make  these 
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decisions  (such  as  mission  brief,  threat  behaviour  and  water  conditions);  how  the  decisions  are 
derived  from  this  information  based  on  expert  ASW  tactical  practice.  This  problem-solving 
knowledge  is  expressed  as  a  hierarchy  of  tasks  and  sub-tasks,  which  is  structured  in  a  way  that 
reflects  how  expert  Observers  decide  on  which  tactics  are  best  for  a  given  scenario.  Making  this 
structure  explicit  is  important  for  validating  the  expert  system,  maintaining  it,  and  explaining  its 
reasoning  to  operators  [6j.  It  is  also  an  important  step  in  taking  experts  systems  from  a  nascent 
technology  towards  an  engineering  discipline. 

Operators  need  to  see  the  effect  of  applying  tasks  in  the  knowledge  base,  as  well  as 
understanding  their  meaning.  Seeing  how  a  task  affects  the  Sensor  Advisor’s  reasoning  for 
different  scenarios  is  a  necessary  part  of  validating  the  knowledge  base.  Enabling  operators  to 
inspect  the  knowledge  base  and  then  test  it  is  the  most  direct  way  of  gaining  acceptance.  Using 
intermediate  knowledge  representations  would  complicate  this  process,  requiring  operators  to 
understand  and  have  confidence  in  the  translation  from  one  representation  to  another. 

4.2  Operability 

A  factor  that  determines  the  acceptability  of  the  Sensor  Advisor  is  the  build  up  of  trust  by  the 
operators  in  the  system.  A  good  model  of  trust  is  described  by  Muir  [71,  in  which  she  describes 
how  trust  changes  over  time  and  is  initially  dependant  on  the  predictability  of  the  machine.  The 
person’s  ability  to  assess  this  property  will  depend  on  his  own  limitations  as  a  decision  maker. 
Later  on  the  trust  in  the  system  will  be  based  on  its  dependability,  where  in  a  risky  situation 
where  the  system  could  have  been  undependable  the  system  provides  a  useful  result.  The  final 
stage  in  the  growth  of  trust  is  the  development  of  faith.  This  is  where  the  operator  believes  the 
system  will  be  dependable  in  the  future.  The  Sensor  Advisor  supports  its  recommendations 
with  concise  rationale  based  on  the  key  decisions  made.  This  contributes  to  the  trust  operators 
place  in  advice  generated  by  the  system. 

Operator  interaction  is  another  important  factor  which  determines  acceptability.  Roth  et  al  [8] 
compares  two  ways  in  which  an  operator  can  interact  with  an  “intelligent”  decision  aid.  The 
capability  for  sharing  in  the  generation  of  a  solution  as  a  means  to  achieving  operator 
acceptance  being  a  key  feature.  This  view  is  supported  further  by  Reason  [9]  who  distinguishes 
between  “prostheses”  and  “tools”. 

A  typical  scenario  for  the  usage  of  most  expert  systems  is:  the  operator  decides  to  use  the 
system;  the  system  controls  data  gathering;  the  system  offers  a  solution  with  some  explanation; 
the  operator  accepts  (acts  on)  or  overrides  the  system  solution.  In  this  form  of  interaction  the 
locus  of  control  resides  with  the  system.  The  operator  is  expected  to  be  its  servant  and  put  in  all 
the  required  information,  then  rapidly  switch  to  be  its  master  and  monitor  and  overrule  it.  The 
system  is  acting  as  a  “cognitive  prosthesis”  to  remedy  deficiencies  in  the  user.  Roth  shows  this 
approach  has  serious  weaknesses  and  prevents  operators  taking  an  active  role  in  the  problem¬ 
solving  process.  He  goes  on  to  suggest  the  alternative  approach  of  a  “cognitive  tool”.  This 
involves  the  operator  as  an  active  problem  solver  in  order  to  cope  with  unanticipated  problems 
and  times  when  the  system  heads  off  on  a  wrong  or  unacceptable  track.  The  Sensor  Advisor 
makes  explicit  its  reasoning,  supports  voluntary  operator  input,  and  indicates  the  boundaries  of 
its  knowledge.  In  this  way  the  operator  is  able  participate  in  the  reasoning  process. 

The  benefits  of  having  operators  remaining  as  active  problem  solvers  is  that  they  can  then 
maintain  supervisory  control,  but  with  reduced  workload.  They  need  to  be  solving  the  problem 
in  parallel  anyway,  so  that  they  know  whether  to  accept  or  reject  the  system’s  suggestions.  If 
they  are  actively  involved  in  this  process,  they  will  have  greater  confidence  in  the  result  and 
will  be  able  to  rapidly  judge  the  system’s  recommendations.  These  ideas  approach  Schuman’s 
“shared  frame  of  reference”  1 10|  in  which  the  system’s  assumptions  about  the  world,  the 
history  of  observations  entered,  the  options  rejected  and  the  current  line  of  reasoning  are  all 
made  explicit.  The  operator  needs  to  be  able  to  assess  the  state  of  the  system  and  recognise 
when  the  system  is  beyond  its  boundary  of  competence,  whether  the  current  line  of  reasoning 
is  due  to  faulty  input  or  faulty  knowledge. 
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5  Conclusions 


The  main  conclusions  resulting  from  this  paper  can  be  divided  into  those  which  relate  to  expert 

systems  development  and  those  which  relate  to  the  design  of  knowledge-based  tactical  decision 

aids.  For  expert  systems  development: 

•  Validation  should  be  an  integrated  part  of  the  complete  expert  system  development  life- 
cycle,  and  aim  to  progressively  build  confidence  that  operator  requirements  can  be  met 

•  Operators  and  their  representatives  should  be  involved  from  the  start  of  development 

•  Tools  to  assist  with  verification  and  validation  of  the  knowledge  base  should  form  a 
significant  part  of  any  expert  systems  methodology. 

For  knowledge-based  tactical  decision-aids: 

•  The  knowledge  representation  used  should  closely  reflect  the  way  operators  reason  about 
which  tactics  to  apply  for  a  given  scenario 

•  Tasks  are  a  good  way  of  expressing  and  structuring  problem-solving  knowledge 

•  Operators  need  to  see  the  effect  of  applying  statements  in  a  knowledge  base,  as  well  as 
understanding  their  meaning 

•  Using  a  knowledge  representation  which  is  both  familiar  to  operators  and  machine- 
executable  is  the  most  direct  way  of  gaining  operator  acceptance 

•  Providing  rationale  based  on  key  decisions  made,  and  enabling  operators  to  share  in  the 
generation  of  solutions  is  an  important  means  to  achieving  operator  acceptance. 
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SUMMARY 

One  of  the  most  important  considerations  in  the  design  of  future  weapon 
systems  will  be  the  introduction  of  tactical  and  systems  automation.  Such 
facilities  will  provide  computer  support  to  the  human  operator  across  the 
full  spectrum  of  mission  management  tasks.  The  growing  importance  of  these 
aids  stems  from  the  continued  drive  to  achieve  greater  operational 
effectiveness  with  an  acceptable  crew  workload.  A  primary  area  of 
application  is  in  the  cockpit  of  a  combat  aircraft,  where  the  increasing 
complexity  of  the  systems  and  severity  of  the  air  battle  environment  place 
intense  demands  on  the  crewman.  This  paper  describes  a  recent  phase  of 
work  in  the  continuing  development  programme  at  British  Aerospace  to 
provide  computer  aided  tactics  in  the  cockpit.  The  particular  tactical  aid 
COMTAC  is  discussed,  outlining  its  main  features  and  describing  how  it  has 
been  installed  into  an  'active  cockpit*  facility  to  examine  the  man  machine 
interface . 

INTRODUCTION 

A  number  of  years  ago,  following  conceptual  discussions  with  GEC,  Ferranti 
and  Smiths  in  the  Industrial  Avionics  Working  Group  (Reference  1),  British 
Aerospace  initiated  an  in-house  programme  of  research  and  development  work 
to  produce  prototype  mission  management  aids  (MMA)  for  use  in  combat 
aircraft.  This  work  has  included  not  only  conventional  programming 
techniques,  but  also  the  use  of  intelligent  knowledge  based  systems 
(Reference  2).  Because  of  the  wide  sphere  of  application  of  mission 
management  aids,  a  co-ordinated  work  programme  is  now  underway  at  all  of 
the  main  sites  of  the  BAe  Military  Aircraft  Division. 

This  paper  describes  a  particular  computer  tactical  aid  called  COMTAC.  It 
is  based  on  earlier  experience  with  a  microcomputer  tactical  aid  called 
MITAC  (Reference  3),  although  COMTAC  is  much  more  powerful  and  has  a  far 
more  extensive  range  of  tactical  algorithms. 

The  whole  programme  of  work  on  mission  management  aids,  of  which  COMTAC  is 
an  example,  grew  out  of  the  realisation  that  the  conventional  technological 
development  path  was  not  viable.  The  provision  of  increasingly  complex 
systems  and  weapons  to  be  operated  in  an  increasingly  severe  air  battle 
environment  results  in  excessive  pilot  workload  ana  reduced  performance. 

As  the  new  systems  and  weapons  are  essential,  in  order  to  deal  with  the 
growing  enemy  threat,  it  is  necessary  to  support  the  crew  with  computer 
aids.  These  take  the  form  of  tactical  aids,  to  assist  the  crew  with  attack 
planning  and  execution,  and  systems  automation  to  assist  the  crew  in  the 
operation  of  onboard  systems  and  weapons. 

As  already  mentioned,  COMTAC  is  a  tactical  MMA.  Its  function  is  to  assist 
the  crew  in  understanding  the  outside  scene,  deciding  which  are  the  most 
important  targets  and  threats,  working  out  a  range  of  alternative  attack 
and  defence  options,  and  then  deciding  on  the  best  course  of  action. 

A  typical  air  defence  scenario,  within  which  such  a  tactical  aid  could  be 
required  to  operate  is  shown  in  Figure  1.  The  scenario  includes  three  main 
types  of  enemy  raid:  attack  on  airborne  early  warning,  enemy  fighter  sweep, 
and  an  escorted  deep  strike  raid.  Such  scenarios  have  been  used  in  the 
development  programme  of  COMTAC  to  demonstrate  and  assess  its 
effectiveness.  In  addition  to  the  primary  airborne  targets  and  threats, 
the  tactical  aid  must  also  deal  with  numerous  other  enemy  and  friendly 
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aircraft  in  the  scene,  as  well  as  threats  from  enemy  around  forces,  e.g. 
SAMs. 

In  addition  to  the  development  of  the  tactical  algorithms,  it  is  also  of 
fundamental  importance  to  design  an  appropriate  man  machine  interface 
( MMI ) ,  with  particular  emphasis  on  display  formats  and  crew  interaction,  so 
that  the  tactical  aid  can  be  of  maximum  benefit.  This  was  achieved  through 
a  parallel  MMI  programme,  closely  related  to  the  algorithmic  developments. 

Finally  it  is  necessary  to  demonstrate  and  assess  the  tactical  aid  in  a 
realistic  environment.  This  was  done  by  programming  the  algorithms  and 
displays  into  an  ’active  cockpit’  facility,  which  could  be  flown  and 
assessed  by  aircrew. 

COMTAC  ALGORITHMS 

The  guts  of  COMTAC  are,  of  course,  its  tactical  algorithms,  which  process 
the  outside  world  data  in  order  to  decide  on  the  best  course  of  action. 

The  functional  architecture  of  COMTAC,  which  shows  the  relationship  between 
the  different  algorithmic  blocks,  is  shown  in  Figure  2. 

After  their  detailed  specification,  the  algorithms  were  developed  and 
tested  on  a  computer  workstation,  before  being  transferred  to  the  ’active 
cockpit’  facility.  In  order  to  complete  this  development  and  testing,  the 
workstation  was  programmed  with  a  number  of  facilities  including  an  outside 
world  model,  containing  dynamic  enemy  aircraft  and  missiles,  through  which 
the  combat  could  be  run  in  real  time.  The  tactical  behaviour  of  enemy 
aircraft  can  be  varied  and  it  is  possible  for  the  operator  to  ’board’  any 
aircraft  in  the  scene  to  get  a  pilot’s  eye  view  of  the  combat  situation  and 
to  vary  aircraft  manoeuvre  of  weapon  launch  decisions.  The  workstation  has 
a  high  resolution  colour  display,  which  is  particularly  useful  for 
presenting  the  results  of  the  tactical  computations.  Although  closely 
related,  the  actual  cockpit  displays  were  developed  separately  as  part  of 
the  parallel  MMI  programme. 

With  reference  to  Figure  2,  the  first  COMTAC  function  is  Situation 
Assessment.  Some  of  the  factors  which  feature  in  the  situation  assessment 
algorithms  are  shown  in  Figure  3.  The  main  purpose  of  Situation  Assessment 
is  to  reduce  the  whole  of  the  outside  scene,  referred  to  as  the  alpha 
scene,  to  a  smaller  selected  number  of  the  most  important  targets  and 
threats,  known  as  the  beta  scene.  This  process  includes  obvious  features, 
like  deletion  of  friendly  tracks  from  the  treat  list,  as  well  as  more 
complex  range  and  urgency  functions,  to  determine  which  enemy  aircraft  will 
come  within  engagement  range  first.  Other  computations  address  target 
behaviour.  A  final,  but  important,  algorithm  decides  the  target/threat  mix 
that  is  to  constitute  the  beta  scene,  to  avoid  overemphasising  either  one. 

The  next  COMTAC  function  is  Attack  Planning  in  which  a  range  of  different 
attack  options  are  computed  against  each  aircraft  in  the  beta  scene.  These 
include  various  tactics  in  terms  of  aircraft  approach  paths  and  missile 
launch  points,  as  indicated  in  Figure  4.  The  aircraft  approach  paths  can 
be  multi  leg,  including  set-up  manoeuvres,  attack  manoeuvres  and  escape 
legs.  Collision,  lead  and  lag  courses  are  computed,  with  the  appropriate 
use  of  energy  management  in  the  vertical  plane,  the  options  being 
constrained  to  ensure  that  the  targets  remain  in  radar  view. 

On  each  attack  option,  full  missile  firing  brackets,  from  maximum  to 
minimum  range,  are  computed  against  primary  and  secondary  targets.  These 
include  representative  performance  of  the  missile  in  each  of  Its  critical 
phases;  an  example  to  illustrate  those  for  a  mid-course  guided  active 
homing  missile  are  shown  in  Figure  5.  Kill  probability  functions,  varying 
with  launch  range,  are  used  to  determine  the  effectiveness  of  each  missile 
launch  opportunity. 

The  third  major  COMTAC  function  is  Enemy  Counter-Attack  Assessment,  where 
the  risks  associated  with  each  of  the  attack  options  is  assessed.  This  is 
done  by  examining  the  attack  paths  and  missile  launch  opportunities  of  the 
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enemy  threat  aircraft  (Figure  6),  using  many  of  the  algorithms  from  Attack 
Planning.  The  effect  of  enemy  missile  counterfire  is  to  produce  kill 
probabilities  which  are  then  converted  into  reductions  in  own  survival 
probability.  Enemy  surface-to-air  missile  attacks  are  included  in  this 
process . 

Following  this  comprehensive  assessment  of  enemy  counter-attack  options, 
sufficient  data  has  been  derived  to  allow  the  next  process  to  Defence 
Planning.  As  indicated  in  Figure  7,  this  process  includes  evasive 
manoeuvres,  jamming  and  the  use  of  decoys.  The  use  of  these  defensive 
measures  increases  own  survival  probability. 

The  above  processes  provide  a  full  set  of  tactical  options,  known  as  gamma 
options,  each  of  which  includes  a  full  set  of  information  on  attack, 
counter-attack  and  defence.  This  forms  the  options  database. 

The  final  COMTAC  function  is  Options  Analysis  and  Ranking,  which  decides 
the  best  option  to  go  for  (the  gamma  star  option)  and  ranks  the 
alternatives  in  a  preferred  order.  This  is  done  by  analysing  the 
cumulative  target  kills  and  own  survival  probability  on  each  option  to 
determine  which  one  maximises  a  special  tactical  value  function.  This 
function  places  different  values  on  the  kills  achieved  against  different 
types  of  enemy  aircraft,  e.g.  bombers,  fighters,  AWACS,  as  well  as 
placing  a  value  on  self.  It  also  weights  the  probability  of  different 
forms  of  enemy  tactical  response,  e.g.  bombers  more  likely  to  carry 
straight  on,  fighters  more  likely  to  turn  and  attack.  The  numbers  in  this 
tactical  value  function  can  be  varied  by  the  user,  depending  on  the  stage 
of  the  war  and  the  tactical  objectives  of  the  mission.  Although  the 
objective  is  always  to  achieve  the  maximum  number  of  target  kills,  this  has 
to  be  balanced  against  own  survival  probability.  With  different  weightings 
the  recommended  option  could  vary  from  one  giving  few  kills  with  no  risk  to 
one  giving  many  kills  with  greater  risks. 

By  pressing  an  appropriate  key  the  workstation  will  display  any  of  the 
gamma  options.  The  operator  can  adopt  the  recommended  attack  or  choose  an 
alternative.  Information  will  be  available  for  the  selected  option  to 
provide  attack  steering  and  missile  launch  control  as  well  as  defence 
cueing.  The  operator  can  fly  the  attack  in  real  time  to  see  how  it 
develops  and  how  well  the  tactical  algorithms  cope  with  the  changing 
situation. 

All  of  the  above  COMTAC  functions  are  executed  on  the  alpha/beta  scene 
every  cycle,  to  produce  updated  options.  For  real-time  applications  in  the 
cockpit,  the  aim  is  to  keep  the  cycle  time  for  these  computations  below  one 
second.  This  requires  the  very  latest  technology  in  compact  and  powerful 
computers  and  considerable  expertise  in  designing  fast  algorithms. 

MAN  MACHINE  INTERFACE 

Having  designed  and  developed  the  COMTAC  algorithms,  the  next  important 
issue  to  be  addressed  is  the  question  of  how  the  pilot  interacts  with  the 
MMA.  This  will  depend  on  his  confidence  in  its  ability  as  a  tactical 
advisor,  bearing  in  mind  that  automation  has  never  been  applied  so 
extensively  in  tactical  areas  which  have  traditionally  been  considered  the 
pilot’s  domain. 

The  underlying  assumption  of  the  MMA  development  is  that  it  can  perform  as 
many  or  as  few  tasks  as  the  pilot  will  sanction  it  to  carry  out.  Whilst 
the  MMA  operates  in  this  assigned  role,  it  is  crucial  that  the  pilot’s 
awareness  is  maintained  of  the  overall  situation  with  which  he  is  faced. 

How  much  information  does  the  pilot  need  in  order  to  monitor  the  MMA,  so 
that  when  required  he  can  take  over  the  tasks  best  suited  to  him?  What  are 
the  best  means  by  which  to  present  this  information  in  the  most  natural  way 
for  the  pilot  to  assimilate? 

In  order  to  examine  such  questions,  a  rapid  display  prototyping  facility 
was  established  on  which  display  formats  could  be  generated,  assessed  and 
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modified  in  an  iterative  process,  all  in  a  short  space  of  time.  Tentative 
ideas  for  presenting  information  to  the  pilot  can  now  be  drawn  on  a  display 
surface  in  hours  rather  than  days  or  weeks.  Iterative  evaluation  and 
development  of  formats  that  show  promise  can  proceed  in  the  same  sort  of 
timescale. 

The  facility  comprises  a  high  resolution  graphics  workstation  to  which  is 
attached  keyboard,  bitpad  and  interactive  mouse,  the  means  by  which  drawing 
instructions  are  specified.  Formats  are  drawn  using  a  variety  of  primitive 
graphic  elements,  in  a  range  of  colours  from  a  palette  of  sixteen  million, 
using  highly  adaptable  symbology  sizes  and  character  fonts.  The  software 
that  allows  this  facility  to  be  used  to  such  good  effect  has  been  specified 
and  generated  in-house. 

The  advent  of  this  quick-look  facility  allows  mind’s-eye  concepts  to  be 
quickly  sketched  out  in  a  representative  fashion  and  stored.  A  range  of 
options  was  developed  from  conventional  two-dimensional  formats  through 
perspective  views  to  pseudo  3D  presentations.  In  parallel  with  this  range 
of  format  options,  numerous  symbology  conventions  were  raised  for 
discussion  and  trial.  One  of  the  most  complex  formats  (Situation 
Assessment)  was  taken  and  symbology  used  in  various  ways  to  differentiate 
between  the  classes  of  data  requiring  presentation.  Tne  merits  of  the 
conventions  were  assessed  and  most  usable  read  across  onto  all  the  chosen 
working  options. 

Assessments  are  being  undertaken  by  cockpit  specialists  and  project 
aircrew,  the  results  being  used  to  refine  the  formats  to  a  good  working 
standard,  gradually  homing  in  on  a  suite  of  optimised  formats. 

The  main  working  format  is  the  plan  situation  display,  which  presents  a 
long  range  view  of  the  overall  scene  surrounding  the  aircraft.  This  can  be 
presented  with  the  full  detail  of  the  Alpha  Scene,  or  as  the  more 
manageable  subset,  the  Beta  Scene.  The  high  priority  tracks  are 
categorised  for  height  band,  sensor  source  providing  the  data,  co¬ 
operating,  unknown  or  hostile.  Hostiles  are  annotated  as  being  designated 
for  attack,  allocated  to  another  co-operating  aircraft  or  just  of  interest. 

Tactical  analysis  of  the  scene  allows  the  generation  of  recommended  attack 
options  for  own  aircraft  on  the  Gamma  display.  The  pilot  is  given  the 
capability  to  cycle  from  the  gamma  star  option  through  the  ranked 
alternatives  prior  to  sanctioning  the  one  he  deems  best. 

Once  this  option  is  chosen,  then  an  attack  steering  format  can  be  selected 
which  presents  a  tunnel  down  which  to  fly.  This  takes  the  form  of  a  series 
of  rectangles  which  define  azimuth  and  elevation  steering  limits  for  an 
approach  and  attack  course,  the  rate  of  advance  of  the  rectangles  giving  a 
speed  cue  and  discrete  event  markers  being  generated  to  indicate  firing 
brackets . 

ACTIVE  COCKPIT 

Having  generated  a  full  set  of  tactical  algorithms  and  a  suite  of  display 
formats  with  symbology  conventions,  the  next  important  step  is  to  make  them 
dynamic  in  as  realistic  a  context  as  possible.  BAe  Military  Aircraft 
Division  operate  a  number  of  mission  simulator  facilities  to  support 
aircraft  projects  and  advanced  research.  Active  cockpit  facilities  at 
Brough  and  Warton  are  being  used  in  this  programme,  to  allow  pilot 
interaction  with  the  MMA  whilst  performing  representative  tasks.  They 
provide  the  displays  and  controls  necessary  for  pilots  to  fly  out  air 
defence  sorties  through  complex  scenarios. 

One  of  the  Warton  'active'  cockpit  facilities  is  shown  diagrammatically  in 
Figure  8.  It  comprises  three  main  elements: 

*  The  assessment  booth,  containing  cockpit  mock-up  and  outside  world 
projection  system. 
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*  The  assessment  control  station. 

*  The  computer  hardware  and  software. 

The  basic  facility  includes  an  aerodynamic  response  model,  which  when 
interfaced  to  the  outside  world  system  and  the  incepters  in  the  cockpit 
allows  the  pilot  to  fly  the  simulation  and  receive  realistic  visual  cues. 

Ba  sic  flight  data  is  provided  by  a  simulated  head-up  display  superimposed 
on  the  outside  world.  Provision  of  aircraft  system  models  and  head  down 
display  formats  for  fuel,  hydraulics  and  engines  ensures  that  the  pilot  can 
be  loaded  with  a  realistic  system  management  task. 

Display  format  control  is  by  means  of  either  multifunction  buttons  on  the 
bezels  or  the  throttle  mounted  XY  controller  for  cursor  control  on  the 
three  display  heads. 

The  set  of  displays  for  mission  management  comprises: 

*  A  radar  format,  which  can  be  shown  in  either  plan  or  range/azimuth 
form. 

*  A  self  defence  format,  which  locates  primary  threats  and  uncorrelated 
RF  sources  within  a  compass  rose. 

*  A  long  range  plan  situation  format,  which  locates  and  identifies 
targets  indicated  by  onboard  and  remote  sensors.  This  display  can  have 
track  or  north  orientation,  different  range  scales,  selective 
decluttering  and  alternative  forms  of  attitude  information. 

*  An  attack  steering  format  in  the  form  of  a  tunnel  of  rectangles. 

The  plan  format  is  used  to  display  the  Alpha  and  Beta  scenes  and  the  Gamma 
options.  When  the  most  promising  attack  option  has  been  selected,  steering 
information  is  provided  on  the  attack  steering  format. 

The  facility  allows  different  scenarios  to  be  introduced  to  test  the 
ruggedness  of  the  MMA.  A  broad  opinion  of  its  effectiveness  will  be  sought 
by  working  closely  with  a  large  sample  of  pilots  in  formal  assessments  on  a 
number  of  missions.  In  this  way  the  scope  of  the  MMA  and  the  necessary  man 
machine  interface  will  be  optimised. 

FUTURE  DEVELOPMENTS 

This  paper  has  described  some  recent  work  on  a  tactical  mission  management 
aid,  addressing  one  key  area  in  the  wider  MMA  scene,  which  covers  all 
aspects  of  tactical  and  systems  automation. 

Many  lessons  have  been  learned  and  insights  gained  from  the  work  done  so 
far,  which  will  be  used  in  a  continuing  programme  of  research  and 
development  to  extend  and  improve  the  tactical  MMA.  This  will  include  new 
and  more  efficient  algorithms  to  represent  aircraft  and  missile 
performance,  development  of  better  tactics  with  enhanced  multi-target 
sequencing,  operation  in  the  jamming  environment,  and  group  operations. 

Work  is  also  under  way  on  new  approaches  to  the  presentation  of  tactical 
information  to  the  crewman  in  innovative  pictorial  form. 

Another  very  useful  outcome  of  the  work  done  so  far  has  been  a  clear 
realisation  of  the  computing  power  required  to  run  a  comprehensive  tactical 
MMA  in  real  time. 

In  addition  to  the  tactical  core  of  MMA  work,  the  programme  will  be 
expanded  to  include  other  important  areas  in  the  total  MMA  system 
architecture . 

The  application  of  intelligent  tactical  and  systems  automation  in  combat 
aircraft  is  seen  as  a  very  powerful  method  of  providing  the  necessary 
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increases  in  operational  effectiveness. 
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Summary  -  The  potential  benefits  of  KBS  in  reducing  crew  workload  and  enhancing 
performance,  especially  during  times  of  exceptional  stress,  are  being  explored  in  an 
Intelligent  Displays  Manager  Demonstrator.  The  prototype  was  sponsored  by  MM4a,  the 
Royal  Aerospace  Establishment,  Famborough,  being  one  element  in  a  broader  spectrum  of 
KBS  work  funded  by  RAE.  Subsequently  private  venture  funding  has  been  used  to 
enhance  the  performance  of  the  demonstrator  and  to  broaden  the  scope  of  the  work.  The 
aim  has  been  to  explore  the  underlying  KBS  mechanisms  necessary  to  anticipate  a  pilot’s 
information  needs  as  a  mission  progresses  and  in  response  to  the  unexpected.  Future  work 
is  directed  towards  the  use  of  KBS  "planned  dialogues"  with  symbols  rather  than  text,  as  a 
means  of  rapidly  conveying  large  quantities  of  complex  information  of  varying  priorities 
and  consequences,  to  a  pilot,  as  an  "unfolding  story"  of  connected  and  consistent 
information. 


Introduction  -  This  paper  addresses  just 
one  aspect  of  the  Human-Electronic  Crew 
as  a  team,  the  management  of  the 
information  displayed  to  a  pilot. 

Electronic  displays  technology,  whether 
using  a  single  large  display  surface  or  a 
number  of  smaller  discrete  surfaces 
allows  ever  more  complex  information  to 
be  presented,  in  a  growing  number  of 
combinations,  using  a  bewildering  array 
of  symbols  and  formats,  and  with  the 
potential  for  an  equally  bewildering  array 
of  switches  or  menus  for  selecting  what 
is  to  be  displayed.  The  management  of 
cockpit  displays  thus  represents  yet  one 
more  element  in  the  workload  of  an 
aiready  very  busy  combat  pilot. 


The  Intelligent  Displays  Manager 
Demonstrator  emulates  some  of  the 
functions  of  a  navigator  in  a  two  man 
machine.  Given  a  knowledge  of  pilot 
inputs,  aircraft  parameters,  aircraft 
sensors,  the  mission  plan,  typical 
occurrences  in  a  mission  and  typical  pilot 
behaviour  and  training  it  attempts  to:- 

*  Estimate  the  pilot’s  mental 
model  of  the  situation. 

*  Estimate  current  pilot  workload. 

*  Anticipate  the  activities  the  pilot 
is  able  to  carry  out. 

*  Set  up  the  corresponding 
displays,  symbology  and  formats. 

The  Concept  -  Fundamental  to  the 
thinking  has  been  the  concept  of  two 
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cooperating  expens  (figure  1).  The 
Aircraft  State  Expert  (ASE)  estimates  the 
pilot’s  mental  model  of  the  total 


during  one  of  a  number  of  knowledge 
gathering  meetings  with  aircrew  of  the 
Experimental  Flying  Dept.,  RAE.  It 


Figure  1  -  The  Intelligent  Displays  Manager  Concept 


situation,  it  determines  what  states  the 
pilot  believes  the  aircraft  is  in.  From  this 
mental  model  the  Displays  Expert 
estimates  current  workload  and  thus  the 
tasks  the  pilot  is  able  to  undertake,  it 
then  determines  what  information  should 
be  displayed  ,  how  and  where. 


describes  conditions,  pilot  actions  and 
options  in  response  to  an  air-to-air 
counter-attack  or  "bounce".  This 
knowledge  of  typical  actions  and  events 
is  built  into  the  rule  sets  or  knowledge 
sources  within  the  Aircraft  State  Expert. 


Knowledge  Representation  -  Schank’s 
notion  of  scripts  or  typical/expected 
sequences  of  events  has  proved  a  very 
useful  way  of  representing  pilot  training, 
typical  actions  and  behaviour,  and  one 
that  is  equally  meaningful  to  both  aircrew 
and  developers.  Figure  2  was  developed 


Workload  Assessment  -  This  is  based  on 
the  notion  that  there  are  a  range  of  tasks 
a  two  man  crew  perform  and  thus  that 
must  be  performed  by  a  pilot  supported 
by  an  electronic  crew  member.  13  task 
areas  have  been  identified,  each  with  an 
associated  priority  and  workload 


according  to 
the  mission 
phase  and 
current  script. 

The  units  of 
workload  are 
arbitrary  and 
relate  to  a 
"perfect"  2  man 
crew  able  to 
handle 

everything.  65 
units  represents 
a  typical 
maximum  for  a 
pilot.  In  figure 
3  the  pilot  can  be  expected  to  carry  out 
the  first  4  tasks  (63  units).  Lower 
priority  tasks  will  be  ignored.  It  follows 
that  an  intelligent  aircraft  should 
recognise  this  limit  and  take 
responsibility  for  those  lower  priority 
tasks. 


The  Displays  Expert  uses  the  list  of  tasks 
that  the  pilot  is  judged  to  be  able  to  carry 
out  to  create  a  "display  list"  of  all 
information  to  be  presented,  with  the 
preferred  display  surface,  symbology  and 
alternatives  in  the  event  of  clutter. 

The  Demonstrator  -  (Figure  4).  The 


current 

demonstrator  is 
built  on 
knowledge  of  a 
long  range  air 
interdiction 
mission,  this 
being  a 
tractable  yet 
sufficiently 
challenging 
focus  for  the 
work.  It  has 

Air-to-Air  Counter-Attack,  the  "Bounce" 


Bounce:  Fight 

1 

Fly:  Control  Aircraft 

20 

2 

Weapons  Delivery 

20 

3 

A/A  Threat  Avoidance:  Position  Aircraft 

15 

4 

Terrain  Avoidance:  Control  Aircraft 

8 

5 

Weapons  t  ECM:  Monitor  Status 

15 

6 

A/A  Threat:  Advise  6  Monitor 

10 

7 

Fly:  Monitor  Aircraft  Systems 

10 

8 

Ground  Threat  Avoidance:  Position  Aircraft 

1 

9 

Ground  Threat  Avoidance:  Countermeasures 

1 

10 

Terrain  Avoidance:  Advise 

8 

11 

Navigate:  Control  Aircraft 

5 

12 

Navigate:  Plan  6  Monitor 

8 

13 

Weapons  6  ECM:  Selection 

0 

Workload  Total 

121 

Figure  3  -  Pilot  Tasks  &  Workload: 
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Figure  4  -  Demonstrator  Structure 


been  implemented  on  2  networked  Sun 
Microsystems  workstations  using  a 
proprietary  real  time  AI  toolkit  whose 
initial  development  was  sponsored  by 
RAE.  In  addition  to  the  2  expert  systems 
there  are  two  areas  of  conventional 
software  written  in  the  "C"  language,  the 
scenario/aircraft  model  and  the  graphics 
software. 


The  team  assumed  initially  that  the 
development  of  the  expert  systems  would 
be  the  most  difficult  and  risky  task,  in 
the  event  achieving  a  demonstrator 
having  near  real  time  performance  using 
conventional  graphics  software  proved 
much  more  difficult,  with  much  effort 
being  spent  in  measuring  and  optinr  mg 
performance.  See  table  I. 


Table  I  -  Demonstrator  Performance 
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Although  the  data  on  a  dynamic  display 
must  be  updated  at  faster  than  25 
frames/second  the  management  or  control 
of  what  is  displayed  can  be  carried  out 
more  slowly,  say  every  500  milli-second. 

Where  Next 

The  (Generalised  State  Estimator  - 
Current  work  has  shown  the  feasibility  of 
estimating  a  combat  pilot’s  mental  model 
of  a  complex  evolving  situation.  We 
believe  that  a  Generalised  State  Estimator 
will  support  the  management  of  a  variety 
of  aircraft  systems:-  stores; 
communications;  threat  assessment; 
routing  and  planning;  emergency  and 
reversionary  action;  as  well  as  highly 
trained  operators  of  other  military  and 
civil  systems.  Recognising  that  a  great 


deal  of  knowledge  will  be  required  in 
any  real  application,  a  Generalised  State 
Estimator  Construction  System  (GSECS) 
has  been  developed.  This  takes 
knowledge  in  the  form  of  script 
diagrams,  generated  using  a  proprietary 
diagramming  tool  and  automatically 
constructs  a  dedicated  state  estimator. 

Planned  Dialogues  -  A  pilot  and 
navigator  convey  significant  amounts  of 
information  to  each  other  through  very 
terse  statements.  We  should  expect  that 
a  pilot  will  wish  to  communicate  with  an 
electronic  crew  member  in  an  equally 
terse  dialogue.  Current  dialogue  research 
is  largely  based  on  the  facilities  of  a 
computer  workstation  and  is  very 
dependent  on  the  use  of  text.  Such 


PILOT  DIRECT 
RESPONSE 


PILOT  INDIRECT 
RESPONSE  VIA 
AIRCRAFT  SYSTEMS 


Figure  5  -  Pilot's  Advisory  and  Prompting  Aid 
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dialogues  are  relaxed  and  conversational. 
This  style  is  not  appropriate  to  a  busy 
cockpit,  where  the  communication  is  via 
switches,  indicators,  symbolic  and 
alphanumeric  displays,  direct  voice  input 
and  synthesised  speech. 

The  goal  of  our  "planned  dialogues" 
work  (figure  5)  is  to  rapidly  convey  to 
the  pilot  a  whole  picture.  Large 
quantities  of  complex  and  competing 
information  with  varying  priorities  and 
consequences  to  a  pilot,  is  presented  as  a 
connected  and  consistent  "unfolding 
story".  The  pilot’s  goals  for  the  dialogue 
are  largely  inferred  as  is  his  current 
workload  so  that  a  minimum  of 
interaction  is  required.  The  machine’s 
goal  is  to  plan  the  most  effective  way  of 
conveying  appropriate  information. 

Outstanding  Issues 

Robust  Communication  -  The  HOTAS 
(Hands  On  Throttle  And  Stick)  concept 
recognises  that  under  some  conditions  a 
pilot  can  become  temporarily  disabled 
from  inputting  commands  to  his  machine. 
Equally  he  can  be  restricted  from 
receiving  information.  A  further 
development  of  the  planned  dialogue 
concept  is  that  of  more  robust 
communication  between  man  and 
machr  using  redundant. 
co»~  ,>le  lentary  and  adaptive  information 
paths. 

Broader  Scenario  -  The  prototype 


Displays  Manager  uses  a  single,  well 
defined  scenario.  A  flyable  displays 
manager  will  require  knowledge  of  a  full 
range  of  scenarios,  air-to-air,  air-to- 
ground,  from  take-off  to  landing. 

GSECS  will  assist  with  system  building, 
but  very  considerable  knowledge 
gathering  will  be  required. 

Intelligent  Displays  Manager  in  an 
Intelligent  Aircraft  -  Although  aircrew 
have  seen  the  demonstrator  a  rigorous 
evaluation  has  not  been  carried  out. 

Most  significant  among  the  comments 
was  the  request  for  more  and  deeper 
information,  with  advice  and  prompting 
at  key  mission  phases  (eg  to  arm  before 
target  engagement).  This  suggests  the 
demonstrator  raised  crew  expectations  by 
making  the  cockpit  displays  more 
"transparent",  an  "intelligent  window" 
into  the  aircraft  systems  and  the  overall 
situation.  Future  development  of  the 
Intelligent  Displays  Manager  should  not 
then  be  of  a  system  on  its  own,  but  rather 
as  a  key  and  integrated  element  in  an 
intelligent  aircraft,  whose  systems  are 
able  to  give  information  as  well  as  data, 
the  Displays  Manager  selecting  the  best 
means  of  presentation. 

Flying  on  the  Limits  of  the  Envelope  - 
The  Displays  Manager  estimates 
workload.  However  the  present 
demonstrator  has  no  means  of  sensing 
and  thus  modifying  its  estimates  in 
response  to  pilot  fatigue  or  injury.  The 
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real  aim  is  to  allow  a  pilot  to  fly  closer 
to  the  limits  of  his  and  his  machine’s 
envelope.  To  achieve,  this  a  more 
important  measure  than  workload  is  the 
degree  to  which  a  pilot  is  in  control  of 
the  situation,  that  is,  the  degree  to  which 
his  mental  model  is  both  accurate  and 
complete.  We  need  to  investigate  how  to 
continuously  measure  this  level  of 
control. 

Conclusion  -  The  Intelligent  Displays 
Manager  should  be  seen  as  part  of  a 
larger  whole,  an  intelligent  aircraft. 
GSECS  provides  the  means  for  building  a 
flyable  displays  manager  covering  a  full 
range  of  scenarios.  Planned  dialogues 
with  more  robust  communication  will 
allow  man  and  machine  to  communicate 
more  effectively.  But  these  are  only  the 
means  to  an  end.  That  end  is  to  give  a 
pilot  the  edge  over  the  opposition, 
allowing  him  to  remain  fully  in  control 
while  operating  on  the  limits  of  the 
envelope.  The  Intelligent  Displays 
Manager  then,  as  a  member  of  the 
human-electronic  crew  has  shown  that 
the  team  can  work  together  by 
demonstrating  the  feasibility  of 
estimating  a  pilot’s  mental  model  of  his 
situation,  of  estimating  his  workload  and 
of  selecting  an  appropriate  set  of 
supporting  displays. 
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FFCS  -  the  German  Pilots  Associate 


W.B.  Herbst  MBB 


Abstract:  As  result  of  the  conceptual  design  work  which  has 
lead  to  the  European  Fighter  Aircraft  (EFA)  it  was 
concluded  that  in  modern  air  combat,  beyond  usual 
air  combat  in  particular,  the  pilot  needs  to  be 
assisted  by  intelligent  on-board  equipment  in  order 
to  fully  exploit  airframe,  avionics  and  weapon 
capabilities.  Such  tactical  flight  director  system 
was  developed  by  MBB ' s  military  aircraft  division 
and  successfully  evaluated  by  the  German  Airforce 
in  a  large  scale  manned  simmulation.  It  was 
demonstrated  that  combat  effectiveness  can  be 

improved  by  a  factor  of  2  to  6  dependant  on  the  typ 


of  air 

combat 

scenario . 

(1) 

Introduction 

The 

impact  of 

new 

air-to-air  weapons  on 

air  combat 

characteristics  and  thus  on  fighter  design  requirements  was 
subject  of  extensive  investigations  early  in  the  EFA 
development  cycle.  In  particular,  it  was  found  that  the 
introduction  of  the  new  generation  of  radars  and  of  AMRAAM 
would  alter  the  traditional  concept  of  using  radar  guided 
medium  range  missels  as  stand-off  weapon.  The 
multi-mode/multi-target  capability  of  new  radars  and  the  more 
flexible  fire  control  scheme  of  AMRAAM  on  both  the  red  and 
blue  side  would  force  opponents  to  maneuver  offensively  and 
defensively  even  at  supersonic  speeds  (ref.  1).  It  was 
concluded  that  beyond  visual  range  (BVR)  air  combat  is  a 
complex  maneuvering  and  weapon  system  control  problem  with 
employment  of  very  peculiar  tactics.  Fi3-_.  _1  shows  the  result 
of  a  typical  engagement.  Firing  distances  are  in  the  order 
of  30  km,  altitude  varies  between  low  level  and  11  km  and 
average  speed  would  be  as  high  as  M  -  1.8.  The  duration  of 
such  engagements  would  be  as  short  as  2-3  minutes  and  there 
is  a  strong  requirement  for  critical  and  rapid  tactical 
decision  making  about  maneuvering  the  aircraft,  operating 
sensors  and  deploying  weapons  in  a  head-down  environment. 

Tactical  displays  -  as  used  in  contemporary  aircraft  -  are 
restricted  to  a  display  of  the  tactical  situation.  The  pilot 
would  have  to  make  his  own  tectical  decisions.  It  was 
concluded  from  combat  simulation  that  due  to  the  complexity 
of  the  situation  and  the  speed  of  rolling  events  the  pilot 
would  be  faced  with  great  difficulties  to  fight  successfully 
even  if  a  perfect  situation  picture  is  provided  to  him. 
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computerized  tactical  decision 


Consequently  the  need  for 
assistance  was  recognized. 

(2)  System  Concept 

Fig. 3  is  a  block  diagram  of  the  Fire  Flight  Control  System 
(FFCS)  as  developed  in  MBB  in  the  1980-1988  time  period.  Its 
main  elements  are 

Sensor  Fusion: 

This  subsystem  is  fed  with  signals  coming  from  the 
aircraft  sensors,  primarily  its  radar  in  combination 
with  other  sensors  as  radar  warning,  IR-sensor,  IFF 
and  cross  communication.  It  develops  a  most  reliable 
set  of  information  about  target  positions  and  target 
maneuvers . 

Sensor  Management: 

Based  on  sensor  fusion  analysis  and  on  an  assessment 
of  situation  including  target  priorization,  provided 
by  the  tactical  processor,  this  subroutine  controls 
the  aircraft  sensors,  primarily  the  radar  in  terms 
of  its  field  of  view,  scanning  pattern,  moding  etc. 
It  unloads  the  pilot  from  any  manual  radar 
operation. 

Tactical  Processor: 

This  is  the  heart  of  the  system.  it  constitutes  a 
real  time  simulation  of  the  on-going  combat  based  on 
stored  information  about  opponents  airframe  and 
weapon  system  performance,  the  real  time  situation 
as  provided  by  sensor  fusion  and  on  the  assumption 
of  best  tactical  behavior  of  all  participating 
players  in  the  game.  This  real  time  simulation 
allows  a  continous  prediction  of  probable  events. 
As  a  result  this  system  developes  tactical  advices 
about  how  to  maneuver  the  aircraft  and  to  deploy  the 
weapons  towards  best  tactical  results,  i.e.  winning 
the  game  and/or  survive. 

Display  and  Control: 

The  tactical  advice ,  developed  in  the  tactical 
processor  has  to  be  communicated  to  the  pilot. 
Eventually,  the  pilot  has  to  make  up  his  own  mind 
about  how  to  fight  and  he  may  -  or  may  not  -  tend 
to  rely  on  the  computer  system.  The  link  to  the 
pilot  is  mechanized  by  a  head-down  display  (HDD)  and 
a  head-up  display  (HUD). 

The  HDD  is  used  to  display  primarily  the  current 
situation  as  processed  by  sensor  fusion  ( Fig . 5 ) .  The 
HUD  is  used  to  provide  to  the  pilot  the  tactical 
advice,  developed  by  the  tactical  processor,  about 
how  to  maneuver  the  aircraft  ( Fig.  4 ) .  It  consists 
of  a  moving  symbol  which  would  have  to  be  consistant 
with  the  advised  maneuver  state.  This  symbol  is 
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commanding  to  the  pilot  continuously  the  "optimum" 
maneuver  according  to  the  decision  making  process  in 
the  tactical  processor. 

Resource  Management 

This  subroutine  runs  a  continuous  record  of 
remaining  weapons,  fuel  and  defensive  devices  and 
advises  the  pilot  about  it. 

The  FFCS  has  been  developed  within  a  eight  years  time  period. 
Extensive  research  was  required  to  develop  proper  algorithms 
particularly  for  the  tactical  processor.  Unfortunately, 
mathematical  gaming  theory  is  not  sufficiently  developed  yet 
to  provide  a  closed  loop  solution  to  the  combat  problem. 
Therefore,  certain  gaming  elements  had  to  be  supplemented  by 
heuristic  methods  as  developed  in  computer  combat  modeling. 

A  very  unique  problem  was  the  man-machine  interface,  the 
interface  between  the  computer  and  the  pilot.  First  of  all, 
this  required  to  run  the  computer  programs  in  real  time  very 
early  in  the  systems  development  and  to  use  real  time  cockpit 
simulation.  Also,  the  entire  combat  scenario  including  the 
opponents  had  to  be  simulated.  Essentially,  the  FFCS  was 
developed  and  matured  using  a  real  time  man  against  computer 
system. 

As  a  prerequisit  for  FFCS  development  the  entire  weapon 
system  hardware  (aircraft,  avionics,  sensors,  weapons  in  the 
read  and  blue  side)  had  to  be  substituted  by  computer  models 
(Fig.  7) 

(3)  System  Evaluation 

The  FFCS  was  developed  in  a  man  vs.  computer  environment  and 
there  was  the  question  about  its  applicability  in  a  man  vs. 
man  environment.  Would  the  system  eventually  represent 
nothing  but  a  very  expensive  computer  game?  Would  a  human 
opponent  be  able  to  outmaneuver  the  opponents  and  win  the 
game  against  the  computer  guided  opponent,  just  like  a  good 
chess-player  may  win  against  a  chess-computer? 

The  system,  therefore,  was  evaluated  extensively  within  a 
large  scale  manned  simulator  experiment  (ref. 3).  The  blue 
side  was  implemented  in  MBB's  dome  simulator  which  was 
connected  via  a  high  speed  optical  cable  with  the  dual  dome 
facility  of  the  IABG  over  a  distance  of  about  2000  m  (Fig. 6) . 
Identical  fighter  aircraft  of  EFA  type  and  the  same  radars 
and  weapons  were  used  for  blue  and  red  opponents.  The  trial 
was  conducted  both  in  a  fighter  vs.  fighter  and  also  in  a 
fighter  vs.  fighter  escorted  intruder  environment  ( Fig. 2) . 
Red  fighters  were  equipped  with  a  standard  (F-18  type)  fire 
control  and  situation  display  system.  Blue  fighters,  in 
addition,  were  equipped  with  FFCS. 

The  experiment  was  carried  out  by  operational  german  airforce 
pilots.  The  campaign  lastet  about  3  weeks  including  extensive 
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training,  system  familar ization  and  the  establishment  of  a 
baseline  without  a  FFCS.  Most  important,  the  pilots  were 
periodically  rotated  between  red  and  blue,  i.e.  "red  pilots" 
have  been  familiar  with  with  "blue  FFCS  tactics".  About  300 
engagements  have  been  conducted,  good  enough  for  the 
generation  of  a  reliable  statistical  result. 


That  result  was  very  promising  in  two  respects: 

a  factor  of  two  was  demonstrated  in  the  fighter  vs. 
fighter  environment  in  terms  of  an  improvement  of 
overall  exchange  ratio. 

a  factor  of  six  was  demonstrated  in  the  fighter  vs. 
fighter  escorted  intruder  environment. 

pilots  evenually  expressed  great  appreciation  and 
acceptance  of  the  system.  The  conclusion  was  that 
they  would  need  such  system  in  modern  BVR  air 
combat.  "Red  pilots"  always  finished  the  engagements 
all  over  wet  and  exhausted.  "Blue  pilots"  came  out 
relaxed  and  smiling. 

In  fact,  the  analysis  of  time  histories  recorded 
durning  the  engagements  reveiled  a  significantly 
higher  stress-level  for  "red  pilots".  Average  "g" 
level  was  higher  and,  in  particular,  peak  "g"  values 
and  "g"-onsets  showed  much  higher  values  of  red 
compared  with  blue. 

In  general  "red  pilots"  were  unable  to  compete  against  the 
FFCS  assisted  "blue"  opponents  and  most  attempts  to  "cheat" 
the  FFCS  have  been  unsuccessful.  Red  was  always  lagging 
behind  blue  in  making  tactical  decisions  and  therefore  blue 
was  able  to  dictate  the  course  of  the  game. 

Pilots  also  were  satisfied  with  the  display  system.  Very  soon 
they  recognised  that  the  command  signal  on  the  HUD  was  giving 
good  suggestions  in  most  situations  and  they  learned  to 
interpret  its  dynamics  and  the  characteristics  of  its  motion. 
In  combination  with  the  HDD  they  managed  to  maintain 
"situation  awareness"  throughout  the  engagement. 

Fig. 8  summerizes  the  results.  It  represents  a  parametric 
analysis  of  increasing  supersonic  maneuver  performance 
( 4g-Machnumber )  and  its  impact  on  BVR  combat  effectiveness 
(lower  curve).  This  curve  would  shift  upwards  significantly 
for  FFCS  assisted  fighter  aircraft.  Within  certain 
constraints  expensive  aircraft  performance  could  be 
substituted  by  incorperation  of  an  FFCS. 
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Abstract 


An  electronic  cockpit  assistant  for  IFR  operations  is  presented, 
as  implemented  in  a  flight  simulation  facility  at  the  University 
of  the  German  Armed  Forces  in  Munich. 

The  aiding  functions  are  primarily  focussed  on  situation 
assessment  and  planning  tasks  during  the  approach  and  landing 
flight  phases.  These  functions  are  aimed  at  achieving  a  similar 
workload  level  for  the  pilot  as  in  the  dual  pilot  case  as  well  as 
enhanced  effectiveness  of  flight  guidance.  Extensive  use  of  speech 
system  capabilities  is  made  with  regard  to  communication  between 
the  pilot  and  the  automatic  aiding  functions. 

Results  of  the  flight  simulation  tests  will  be  presented. 


1 .  Introduction 


Today's  civil  air  transportation  is  characterized  by  flights  under 
Instrument  Flight  Rules  (IFR).  This  kind  of  flight  operation 
guarantees  flight  execution  with  almost  full  independence  of  the 
veather  conditions.  Lacking  visual  references,  the  complexity  of 
the  flignt  systems  and  IFR  procedures,  however,  cause  accidents  as 
a  result  of  pilot  errors  [1]. 

To  address  the  problem  of  IFR  flights,  the  single-pilot  IFR  flight 
(SPIFR)  as  an  application  example  has  been  selected  with  regard  to 
the  fact  that  the  relative  total  of  accidents  for  SPIFR  flights 
due  to  pilot  error  is  significantly  higher  than  for  the  dual-pilot 
case.  An  electronic  Assistant  for  SPIFR  Operation  (ASPIO)  has 
been  developed  to  assist  the  pilot  in  situation  assessment, 
planning  and  plan  execution.  In  particular,  assistance  is  provided 
for 


-  understanding  the  current  flight  situation  with  regard  to 
external  and  internal  events 

-  replanning  the  flight  route  (if  necessary) 

-  executing  the  actual  flight  plan 

-  monitoring  the  consistency  between  flight  plan  and  control 
actions 

The  system  has  been  implemented  and  tested  in  a  flight  simulator 
with  good  acceptance  by  the  pilots. 
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2.  Structure  of  the  ASPIO  system 


To  achieve  the  aforementioned  assisting  functions,  ASPIO  has  been 
structured  in  several  modules  [2],  as  depicted  in  figure  1. 


Fig  1 i  Structure  of  ASPIO  modules 


For  ATC  communication  it  is  posited  that  a  two  way  data  link  will 
be  available  at  the  time,  when  this  kind  of  systems  might  come 
into  service.  This  results  in  ATC  instructions  being  directly  fed 
into  the  ASPIO  system. 

The  aircraft  interface  on  the  ASPIO  side  is  established  by  a  data 
pool,  which  contains  all  aircraft  relevant  data  about  flight 
status  (including  autopilot  settings,  radio  navigation  and 
communication  settings  or  status  of  aircraft  subsystems). 

The  pilot  interface  comprises  all  components  for  the  communication 
between  ASPIO  and  the  pilot.  Extensive  use  is  made  of  speech 
communication  in  either  way.  The  pilot  inputs  into  ASPIO  can 
optionally  be  carried  out  by  speech  messages  in  analogy  to  the 
phraseology  of  the  communication  between  pilot  and  co-pilot  in  a 
two-man  cockpit . 

According  to  the  specified  functions,  there  are  three  main 
functional  blocks  for  planning  and  situation  assessment,  plan 
execution  and  monitoring. 
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The  planning  functions  of  ASPIO  are  performed  in  the  Automatic 
Flight  Planner  (AFP).  This  module  is  activated  when  significant 
deviations  from  the  actual  flight  plan  occur  or  can  be 
anticipated.  This  is  the  case  if  new  ATC  instructions  are  not  in 
accordance  with  the  flight  plan  or  if  adverse  weather  conditions 
occur.  The  AFP  checks  whether  the  flight  plan  is  affected  and 
performs  replanning  if  necessary.  The  planning  results  are 
presented  to  the  pilot  as  recommendations.  If  not  corrected  by  the 
pilot,  these  results  then  replace  former  flight  plan  instructions 
and  serve  as  an  input  into  the  following  ASPIO  modules. 

Automatic  management  of  flight  plan  execution  is  performed  by  the 
Model  Pilot  Flying  (MPF) .  The  flight  plan  set  up  by  the  AFP  is 
used  to  determine  the  actions  the  pilot  is  supposed  to  carry  out 
during  the  various  flight  segments.  To  achieve  this,  the  MPF  is 
construed  as  a  reference  model  of  the  pilot.  It  controls  all  the 
necessary  actions  by  firing  rules  that  are  pertinent  to  actual 
flight  goals  or  subgoals.  There  are  also  rules  for  transition  from 
one  goal  to  another  or  to  the  processing  of  ATC  instructions. 

The  pilot  actions  expected  by  the  MPF  serve  as  an  input  to  the 
Monitor  (MON).  This  module  compares  these  expectations  with  the 
actual  activities  of  the  pilot  during  the  execution  of  the  flight. 
If  there  are  any  inconsistencies,  the  MON  sends  messages  to  the 
pilot  by  using  the  speech  output.  In  this  case,  a  feed  back  to  the 
AFP  and  MPF  modules  also  exists . 

To  assist  the  pilot  in  executing  the  flight  plan,  the  Automatic 
Pilot  Not  Flying  (APNF )  offers  a  variety  of  functions  usually 
performed  by  the  co-pilot  in  the  two-man  cockpit  crew. 

Among  these  functions  are  instrument  setting,  flap  and  gear 
setting,  ATC  communication,  checklist  execution  and  callout 
procedures,  performed  via  speech  messages.  The  APNF  can  also  be 
directly  tasked  by  the  pilot  with  respect  to  navigational 
calculations  or  requests  about  flight-relevant  information. 

The  last  module  of  the  ASPIO  system  is  an  autopilot  (AP)  which  can 
be  used  by  the  pilot  and  by  the  APNF  as  well.  Therefore,  the  pilot 
has  the  possibility  to  hand  over  control  of  the  aircraft  to  ASPIO 
in  the  same  way  as  he  can  pass  it  on  to  the  co-pilot  in  a  two-man 
cockpit.  In  that  case,  the  MPF  module  will  accept  the  role  of 
tasking  the  APNF,  which  sets  the  AP  modes  and  the  command  values. 


3.  Simulation  facility 

The  ASPIO  system  is  implemented  in  the  flight  simulation  facility 
shown  in  figure  2. 

The  central  computer  is  a  UNIX  IRIS  4D/140GTX  Graphics  workstation 
with  four  central  processor  units.  Aircraft  dynamics,  autopilot, 
radio  navigation  signals  and  wind  characteristics  are  simulated 
and  a  high  performance  head  down  instrumentation  display  is 
generated.  Furthermore,  the  workstation  is  used  to  run  the  ASPIO 
modules  APNF,  MON,  MPF  and  AFP  and  to  perform  the  interfacing  with 
speech  input  and  output,  the  stick  force  simulation  unit  and  a 
control  and  display  panel.  The  image  outside  vision  is  generated 
by  additional  IRIS  workstations.  Also  a  radar  display  for  use  as  a 
combined  ATC  controller/instructor  workstation  is  installed. 
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Fig  2i  Experimental  setup 


4.  Evaluation  of  the  ASPIO  system 

The  ASPIO  system  has  been  tested  on  quite  realistic  conditions. 
The  possible  benefit  with  regard  to  flight  safety  has  been 
evaluated.  The  following  criteria  have  been  considered: 

-  flight  accuracy 

-  pilot  errors 

-  duration  and  quality  of  planning  and  decision  making 

-  pilot  workload 

-  pilot  acceptance 

Three  different  IFR  scenarios  have  been  developed  comprising 
typical  standard  situations  together  with  unanticipated  events  and 
emergency  cases  [3].  Nine  professional  pilots  have  been  available 
as  subjects. 

For  the  evaluation  of  flight  accuracy  the  standard  deviation  of 
the  airspeed  from  the  required  one  has  been  used.  This  parameter 
had  to  be  manually  controlled  by  the  pilot.  In  all  cases,  the 
evaluation  of  the  airspeed  time  histories  shows  that  there  are 
significantly  greater  deviations  from  the  required  speed  before 
they  are  discovered  and  corrected  by  the  pilot.  It  can  be  stated 
that  the  improvement  in  flight  accuracy  with  ASPIO  is  highly 
significant . 
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Data  for  the  evaluation  of  the  pilot  errors  and  of  the  duration 
and  quality  of  planning  and  decision  making  could  be  elicited. 
Using  ASPIO,  no  pilot  errors  have  been  observed.  Without  ASPIO, 
different  errors  occured.  Some  of  them  could  lead  to  compromising 
safety.  Considering  the  planning  and  decision  making  functions, 
excellent  performance  of  the  system  became  evident.  These 
processes  have  been  significantly  accelerated.  Problem  solving 
with  respect  to  the  necessity  of  selecting  a  destination  alternate 
took  up  to  1.5  minutes  as  pilot  planning  time.  The  corresponding 
planning  process  in  the  AFP  module  followed  by  the  speech  output 
to  the  pilot  needed  only  about  2  seconds.  All  automatically 
derived  planning  results  have  been  accepted  by  the  pilots . 

The  pilot  workload  during  the  test  runs  has  been  determined  by 
means  of  the  SWAT  method  (subjective  workload  assessment 
technique)  in  combination  with  secondary  task  measurements 
(tapping).  The  results  show  a  reduction  of  the  pilot  workload 
during  all  scenarios  although  the  correlation  between  the  results 
of  both  methods  is  not  very  high  (r=0.35). 

The  pilot  acceptance  of  the  ASPIO  system  has  been  proved  through 
the  evaluation  of  a  questionnaire  using  the  technique  of  the 
semantic  differential. 


5.  Concluding  remarks 

To  assist  pilots  in  IFR-operations ,  the  ASPIO  system  has  been 
developed  and  implemented  on  a  flight  simulator  for  the  purpose  of 
thorough  system  testing. 

Tesc  runs  have  been  carried  out  showing  a  very  high  pilot 
acceptance  rate.  The  evaluation  results  highlight  improvement  in 
system  performance  and  avoidance  of  major  pilot  error 
consequences.  The  positive  impact  of  the  ASPIO  system  on  flight 
safety  has  been  proved. 
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The  classical  method  for  determining  the  role  of  the  human  in  a  complex  system 
involves  allocation  of  functions  or  tasks  to  human  or  machine  performance. 

Function/task  allocations  can  be  either  static  or  dynamic.  Static  allocations  identify 
which  functions  or  tasks  should  be  allocated  to  human  performance  vs  machine 
performance  based  on  an  assessment  of  the  requirements  associated  with  the 
function/task  and  the  unique  capabilities  and  limitations  of  the  human  and  machine. 

Static  allocations  are  usually  made  on  the  basis  of  lists  (Fitts’  Lists)  which  compare  the 
relative  capabilities  and  limitations  of  human  and  machine  performance  in  specific 
dimensions. 

Dynamic  allocations  make  the  assumption  that  the  optimum  allocation  strategy  can 
change  with  operational  conditions,  workloads,  and  mission  priorities.  According  to 
Rouse  (1977)  a  dynamic  approach  allocates  a  particular  task  to  the  decision  maker  (man 
or  machine)  which  has  the  resources  available  at  the  moment  for  performing  the  task. 
Rouse  (1981)  identified  the  advantages  of  a  dynamic  approach  as  compared  with  a  static 
approach  as:  improved  utilization  of  system  resources;  less  variability  of  the  human's 
workload;  and  providing  the  human  with  improved  knowledge  of  the  overall  system. 
Revesman  and  Greenstein  ( 1 983)  recommended  an  approach  wherein  the  human  and 
computer  work  on  tasks  in  parallel  with  the  computer  selecting  actions  so  as  to  minimize 
interference  with  the  human.  Here  the  human  is  not  forced  to  change  planned  actions  he  or 
she  retains  the  primary  role  in  the  system.  This  implementation  requires  that  the 
computer  must  make  predictions  about  the  human’s  actions  and  must,  therefore,  have  a 
model  of  the  human  in  terms  of  the  actions  he/she  will  take  at  a  point  in  time  and  under 
cerlam  circumstances.  The  computer  would  use  this  model  of  human  decision  making  to 
predict  the  human's  actions  and  to  select  other  actions  which  do  not  replicate  or  interfere 
with  the  human's  actions.  The  notion  of  adaptive  human-computer  interfaces  was 
expounded  by  Norcio  and  Stanley  (1988).  An  interface  can  be  adapted  to  the  user  in  two 
ways:  enabling  the  user  to  modify  the  interface;  and  dynamic  adaptation  wherein  the 
system  itself  modifies  the  interface.  This  latter  approach  is  designated  the  adaptive 
interface.  It  changes  with  respect  to  the  particular  user  and  current  context.  The 
information  that  the  adaptive  interface  needs  includes  four  domains: 
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•  knowledge  of  the  user  (expertise  with  the  system); 

•  knowledge  of  the  interaction  (modalities  of  interaction  and  dialogue 
management); 

•  knowledge  of  the  task/domain  (goals);  and 

•  knowledge  of  the  system  (characteristics). 

According  to  Woods  (1985)  the  role  of  the  human  has  shifted  with  increased  control 
automation  and  developments  in  computational  technologies.  The  shift  is  away  from 
perceptual-motor  skills  needed  for  direct  manual  control  to  cognitive  skills  such  as  those 
required  to  support  such  roles  as  monitor,  planner,  and  fault  manager.  The  key  to 
effective  application  of  computational  technology  is  to  conceive,  model,  design,  and 
evaluate  the  joint  human-machine  cognitive  system.  The  configuration  or  organization  of 
the  human  and  machine  components  is  a  critical  determinant  of  the  performance  of  the 
system  as  a  whole.  This  means  using  computational  technology  to  aid  the  user  in  the 
process  of  reaching  a  decision,  not  to  make  or  recommend  solutions.  If  joint  cognitive 
system  design  is  to  be  effective,  we  need  models  and  data  that  describe  the  critical  factors 
for  overall  system  performance  (Woods,  1985). 

One  specific  approach  for  addressing  the  role  of  the  human  in  a  complex  man- 
machine  system  has  been  developed  by  Carlow  Associates  for  the  US  Army  Human 
Engineering  Laboratory.  This  approach,  designated  the  HFE/MANPRINT  IDEA  (Integrated 
Decision/Engineering  Aid),  and  described  by  Malone  fila [  (1989)  addresses  the  issue  of 
establishing  the  optimum  role  of  the  human  in  a  three  Step  process:  1)  identifying 
candidate  roles  of  the  human;  2)  identifying  specific  requirements  attendant  to  these 
roles;  and  3)  modelling  human  pedormance  as  expected  in  the  selected  set  of  assigned 
roles.  In  dealing  with  human-computer  systems  it  is  important  to  realize  that  the  issue 
is  not  so  much  defining  the  allocation  of  system  functions  or  tasks  to  human  or  machine 
performance  as  establishing  the  role  of  man  in  the  system.  In  a  human-machine  system 
where  both  components  are  equally  competent  to  perform  individual  functions  and  tasks, 
the  design  issue  is  to  determine  the  role  of  the  human  vs  automation  in  the  performance  of 
each  function  or  task.  The  emphasis  on  the  role  of  human  in  the  system  acknowledges  the 
fact  that  the  human  has  some  role  in  every  system  function  or  task.  In  some  cases  that 
role  may  encompass  actual  performance  of  the  function  or  task.  It  is  also  important  to 
realize  that  an  assigned  role  for  human  performance  may  change  with  changes  in 
operational  conditions.  Thus  a  task  optimally  performed  by  a  human  under  certain 
conditions  of  workload,  time  constraints,  or  task  priority,  may  be  more  optimally 
automated  under  other  conditions  It  is  also  important  to  keep  in  mind  that  automating  a 
function  or  task  does  not  logically  mean  that  the  human  does  nol  have  a  role,  that  he  or  she 
has  effectively  been  designed  out  of  the  system  for  fhaf  specific  function  of  task.  Rather, 
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in  an  automated  function  or  task,  the  role  of  the  human  is  that  of  a  manager,  monitor, 
decision  maker,  system  integrator,  or  backup  performer. 

In  the  IDEA  methodology  the  candidate  roles  of  the  human  are  developed  through 
application  of  an  automated  tool  designated  the  "Role  of  Man  Tool".  This  tool  provides  the 
analyst  with  the  capability  to  import  a  set  of  functions  or  tasks  and  to  assign  roles  to 
human  performance  and  automation  in  the  performance  of  each  function  and  task.  As  each 
function/task  is  presented  to  the  analyst,  a  decision  is  required  as  to  which  component 
(human  or  machine)  should  be  the  performer  of  the  function  or  task.  Where  an 
assignment  cannot  be  readily  made,  the  analyst  selects  a  consultation  capability  *rom  the 
tool,  and  the  tool  presents  a  series  of  questions  where  the  analyst  is  asked  to  scale  some 
dimension  of  the  task,  operational  conditions  and  environment,  user  capabilities,  and 
mission  priorities,  and,  based  on  analyst  responses,  the  tool  recommends  that  the  task  be 
assigned  to  human  or  machine  performance.  In  each  case  where  an  assignment  of  task 
performance  has  been  made,  the  analyst  is  asked  to  identify  the  role  of  the  human,  and  the 
role  of  the  machine  in  the  performance  of  the  task. 

The  assigned  roles  for  each  task  are  then  exported  to  the  IDEA  automated  task 
analysis  tool  where  specific  requirements  for  task  performance  are  identified  for  each 
task,  under  the  specific  allocation  strategy  and  role  assignments.  The  task  analysis  tool 
comprises  a  data  bank  of  issues  and  concerns  for  human  performance  of  system  tasks  as 
affected  by  the  selected  roles  of  the  human  and  the  machine  in  the  completion  of  the  tasks. 
For  tasks  which  are  cognitive  in  nature,  by  reason  of  the  task  itself  or  the  assigned  role 
of  the  human  in  the  performance  of  the  task,  the  task  data  are  exported  to  an  IDEA 
Cognitive  Task  Analysis  Tool  for  a  refined  analysis  addressing  the  cognitive  aspects  of 
required  human  performance,  and  the  resultant  task  data  are  then  imported  back  into  the 
Task  Analysis  Tool. 

The  results  of  the  task  analysis  are  then  exported  to  the  NETWORK  IDEA  tool  which 
describes  task  sequences  in  a  graphic  flowchart  format,  with  task  descriptions  available 
m  text  format.  The  task  descriptions  maintained  in  the  NETWORK  tool  comprise  a  subset 
of  the  requirements  derived  for  each  task  in  the  Task  Analysis  Tool.  These  task 
descriptions  include  specification  of  the  performer  of  the  task,  the  tasks  which  must 
precede  the  specific  task,  and  the  tasks  which  are  dependent  on  the  specific  task,  the 
designation  of  the  role  of  the  human  in  task  performance  if  other  than  performer,  the 
estimated  time  required  for  task  completion,  and  the  process  variables  associated  with 
performance  or  tne  task  I  ocess  variables  include  factors  that  have  a  bearing  on  task 
performance  and  which  can  vary  for  any  simulation  exercise.  Process  variables  typically 
include  capabilities  or  readiness  of  aircraft  systems,  operational/environmental 
conditions,  mission  data,  and  threat  characteristics. 
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The  NETWORK  data  are  then  exported  to  the  IDEA  simulation  tool,  SIMWAM 
(Simulation  for  Workload  Assessment  and  Modeling)  for  exercising  the  task  sequence  as 
specified  in  the  NETWORK  tool.  SIMWAM  is  an  interactive,  microprocessor-based 
simulation  of  human  performance  and  workload.  It  was  originally  developed  by  Carlow 
Associates  tor  the  US  Navy  in  addressing  the  question  of  the  impact  of  the  introduction  of 
automated  status  boards  on  manning  levels  of  the  aircraft  carrier  aircraft  management 
system.  The  system  currently  requires  36  operators  to  control  the  launch  and  recovery 
of  carrier-based  aircraft.  A  simulation  was  conducted  of  the  task  sequences  required  for 
each  of  the  36  operators  to  launch  11  aircraft  and  simultaneously  recover  12  aircraft 
using  the  SIMWAM  model.  A  second  simulation  was  completed  for  the  situation  wherein 
task  sequences  had  been  altered  as  a  function  of  the  introduction  of  automated  status 
boards.  Comparison  of  the  performance  effects  and  workloads  under  each  simulation 
condition  indicated  that  system  manning  could  be  reduced  by  11%  (elimination  of  4 
billets)  with  the  introduction  of  automated  status  boards. The  Role  of  Man  Tool,  Task 
Analysis  Tool,  and  SIMWAM  have  been  applied  in  an  integrated  manner  to  the  analysis  of 
human  performance  requirements  for  the  Forward  Area  Air  Defense  System  (FAADS) 
built  on  the  Bradley  vehicle,  for  FMC.  The  simulation  provided  concepts  for  assigning 
roles  of  human  performance  as  a  function  of  FAADS  weapon  suite.  While  the  application 
of  the  IDEA  tools  for  defining  roles  and  requirements  for  human  performance  in  systems 
has  been  limited  to  multi-operator  systems,  the  tools  are  directly  applicable  to  the 
question  of  the  role  of  the  single  human  pilot  in  cockpits  of  the  future.  In  this  regard  the 
Role  of  Man  tool  will  support  the  determination  of  the  feasible  allocations  of  functions  to 
human  or  automation  and  will  assist  in  the  determination  of  the  roles  of  the  human  pilot 
in  functions  assigned  to  automation.  The  Task  Analysis  and  Cognitive  Task  Analysis  tools 
will  support  the  oerivation  of  requirements  associated  with  each  allocation  strategy  and 
role  of  human  model.  The  NETWORK  tool  will  allow  the  graphic  depiction  of  the  sequence 
of  pilot  functions  or  tasks  and  will  ensure  that  these  sequences  are  internally  consistent. 
The  SIMWAM  tool  will  identify  potential  performance  problems  and  will  quantify  the 
workload  of  the  pilot  for  a  simulated  mission  under  the  candidate  function  allocation 
stra'agies.  The  net  result  of  the  application  of  these  tools  is  a  first  approximation  of 
which  roles  of  the  human  are  feasible,  what  problems  are  to  be  expected  in  specific  role 
of  human  models,  and  what  human  performance  characteristics  should  be  further 
investigated  in  more  comprehensive,  but  more  expensive  man-in-the-loop  simulations. 

Figure  1  depicts  the  relationships  among  IDEA  tools.  As  indicated  in  this  figure,  the 
Role  of  Man  Tool  produces  candidate  function/task  allocation  strategies  which  are 
analyzed  to  greater  detail  by  the  Task  Analysis  and  Cognitive  Task  Analysis  Fools.  Task 
. equipments  data  are  exported  to  the  NETWORK  task  sequencing  tool,  where  graphic 
depictions  of  function  or  task  sequences  are  developed.  The  NETWORK  tool  also  formats 
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Methods  (or  Determining  the  Role  of  the  Human  in  Cockpits  of  the  Future 


the  function/task  data  for  the  SIMWAM  human  performance  and  workload  simulation  tool. 
The  SIMWAM  tool  identifies  workload  imbalances  and  performance  problems  with 
specific  function  or  task  allocation  strategies.  Results  of  the  SIMWAM  simulations  are 
then  fed  back  to  the  Role-of-Man  Tool  for  final  determination  of  the  optimum  role  of  the 
human  in  cockpits  of  the  future. 


ALTERNATE  STRATEGIES 
FOR  FUNCTION/TASK 
ALLOCATION 


TASK  REQUIREMENTS 


Figure  1. IDEA  Tool  Relationships 
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Background: 

A  need  exists  to  develop  a  standardized  functional  interface 
(an  Interface  Control  Description)  between  the  crew  members  and 
the  displays  and  controls  required  to  accomplish  missions.  This 
need  is  born  out  of  practices  which  have  dealt  with  crew  station 
design  as  a  collection  of  subsystem  terminal  interfaces  of 
individual  displays  and  controls. 

During  the  I960  and  70* s  crew  station  design  evolved  into 
a  series  of  military  standards  that  described  each 
electromechanical  display,  coupled  with  an  overall  configuration 
military  standard  geographical  placement  of  these  displays  and 
controls.  The  crew  member  was  also  placed  in  a  position  where  he 
or  she  could  have  visual  and  manual  access  to  these  displays  and 
controls  while  maintaining  an  out-the-window-view  for  primary 
flying  tasks.  Superimposed  on  this  somewhat  orderly 
configuration,  the  electronic  display  was  unleashed.  No  longer 
were  the  restrictions  of  previous  electromechanical  controls  and 
displays  meaningful.  Now  different  references,  symbols,  images 
and  displays  interactions  could  be  had  through  software  editing 
and  development.  The  familiar  crew  station  configuration  had 
been  changed  and  no  one  knew  the  consequences.  Each  manufacturer 
was  free  to  propose  "the  solution"  as  long  as  the  customer  was 
satisfied,  "it"  became  the  standard  (until  the  next  display  was 
produced) . 

At  this  same  time  new  and  improved  sensor,  weapons,  and 
mission  management  capability  made  it  possible  to  quadruple  the 
information  to  the  crew.  All  possible  options  were  provided 
regardless  of  the  potential  for  use  since  no  one  wanted  to 
restrict  the  "users"  capability  to  employ  the  new  wizardry  (who 
knew  what  the  battle  would  demand  for  a  system  that  would  not  be 
fielded  for  the  next  7  to  10  years) .  The  result  was  an  over 
abundance  of  capability  and  an  overwhelming  number  of  paths  to 
accomplish  the  mission  functions. 

For  example,  a  current  production  aircraft  has  52  different 
employment  modes  of  the  weapons  and  sensors  it  carries.  It  is 
not  surprising  that  the  crews  learn  to  use  only  a  very  few  of 
these  and  can  easily  become  confused  if  a  switch  is  misplaced  and 
slips  into  another  mode  of  operation.  In  addition,  each  of  these 
52  modes  of  operation  have  from  7  to  14  procedural  steps  that 
have  to  be  executed  by  memory  to  accomplish  a  given  function. 

Not  only  are  the  steps  different  but  the  logic  is  different.  (I  ' 
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feel  free  to  be  critical  of  this  design  since  I  was  deeply 
involved  in  its  conception  and  development  since  1977) .  The 
impact  of  this  design  is  viewed  as  misused  weapon  system 
capability  since  many  modes  are  never  employed;  but  the  real  cost 
is  in  training.  Due  to  the  design  that  we  are  flying  coupled 
with  reduced  training  dollars  the  crews  are  required  to  use  most 
of  their  flying  hours  allocation  for  meeting  proficiency  training 
requirement.  With  little  educational  hours  available  for 
dedicated  mission  tactical  training  the  crews  must  accomplish  the 
mission  training  at  the  same  time  that  they  are  achieving  their 
proficiency  training  requirements. 

At  great  expense,  crews  are  currently  trained  to  fly  a 
particular  aircraft.  Because  there  is  no  standard  for  the 
functional  interface  between  the  crewmember  and  the  electronic 
systems  of  the  air  vehicle,  previously  learned  knowledge  has 
little  utility  when  the  same  crewmember  must  fly  in  different 
aircraft.  The  differences  in  aircraft  system  designs  causes  wide 
disparities  in  various  aircraft  avionics  functional  interfaces. 
Therefore,  there  is  little  benefit  or  leverage  from  previous 
training  on  other  aircraft  systems.  Even  for  experienced 
crewmembers,  task  training  costs  remain  high  and  consume  the 
majority  of  flight  hours  available  for  pure  mission  training. 

With  fewer  mission  training  hours  available,  crewmember 
performance  in  high  workload  situations  may  be  adversely 
affected. 

With  advancing  technology,  particularly  in  the  area  of 
knowledge  based  systems,  a  wide  variety  of  functions  currently 
performed  by  human  crewmembers  will  be  able  to  be  performed  by 
aircraft  electronic  systems.  Without  direction  and  planning, 
functional  allocation  in  systems  design  could  be  haphazard  and 
current  differences  in  the  operator  functional ’interfaces  between 
aircraft  platforms  could  become  even  more  diverse.  Major  DoD 
initiatives  in  the  same  areas  of  avionics  integrated  systems  and 
hardware/software  standardization  will  provide  new  opportunities 
for  automating  functions.  Given  this,  a  program  to  standardize 
the  interface  between  human  crewmembers  and  virtual  electronic 
crewmembers  could  have  very  large  payoffs.  The  payoffs  could  be 
realized  not  only  for  new  weapon  system  developments,  but  also 
for  retrofit  applications  (within  service,  multiservice,  and 
international) . 

The  MANPRINT  (Manpower  and  Personnel  Integration)  program 
brought  with  its  inception  the  promise  that  we  can  no  longer 
afford  to  look  at  each  of  the  domains  of  MANPRINT  (manpower, 
personnel,  safety,  biomedical  and  health  hazards,  human  factors 
engineering,  and  training)  as  separate  entities  to  be  applied 
individually  or  not  at  all.  Each  development  must  fully  research 
and  develop  the  impact  and  product  of  each  domain  for  the 
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synergistic  improvement  of  the  man-machine  interface.  The 
definition  of  the  work  split  between  the  human  crew  members  and 
the  interaction  with  the  electronic  crew  member  in  a  consistent 
mission  functional  manner  is  essential  for  the  MANPRINT  impacts 
of  future  weapon  systems  crew  stations. 

This  paper  proposes  the  development  of  a  plan  to  define  the 
MANPRINT  requirements  for  specification,  design,  and 
documentation  of  man-machine  functional  interfaces.  Initial 
application  would  be  to  Army  rotary  wing  aircraft.  The  resultant 
plan  would  include  interfaces  with  other  ongoing  DoD 
standardization  thrusts.  It  would  also  include  a  strategic 
implementation  roadmap. 

Both  the  US  Air  Force  and  the  US  Army  are  working  on 
research  projects  that  will  directly  contribute  to  this  effort. 
The  first  effort  which  I  wish  to  discuss  is  the  US  Army  Research 
Institute  Aviation  R&D  Activity  work  to  identify  the  mission 
functional  requirements  across  all  Army  aircraft.  To  date  they 
have  completed  the  AH64,  UH60,  CH47D,  OH58D  and  the  LHX  mission 
functional  allocation  timeline  analyses. 

This  has  produced  a  firm  foundation  of  mission  functional 
definition  that  is  not  contaminated  with  the  individual  crew 
station  configuration  until  the  analysis  drops  below  the  function 
level  to  the  individual  task  level.  The  mission  is  first  broken 
down  into  mission  segments  and  then  to  the  functional  mission 
requirements.  It  is  at  this  level  of  the  functional  mission 
requirement  that  I  feel  the  strongest  and  still  most  meaningful 
identification  of  the  definition  of  the  crew  interface  control 
description  occurs. 

The  second  work  is  conducted  by  Robert  G.  Eggleston  of  the 
U.S.  Air  Force  Armstrong  Aeromedical  Research  Laboratory.  His 
work  on  exploring  the  development  of  acquisition  and  development 
of  the  interface  design  process  appears  to  be  directly 
applicable.  The  general  problem  that  he  sees  is  that  of 
developing  knowledge  acquisition  for  creating  an  expert  system 
(such  as  the  Air  Force  Pilot  Associate  Program)  which  captures 
applied  domain  expertise  for  use  in  the  creation  of  a  computation 
emulation  of  an  expert. Initially  their  goal  is  to  produce  or 
build  a  cognitive  rather  than  a  computational  model.  They 
believe  "that  the  generation  of  a  cognitive  model  prior  to  the 
creation  of  a  computational  model  would,  by  creating  a 
specification  enhance  the  construction  of  the  computational  model 
tools. " 

My  understanding  of  the  relationship  between  these  two 
activities  is  that  they  both  are  focusing  on  the  interface  as  an 
entity  within  itself.  Through  the  successful  identification  of 
this  entity  referred  to  as  the  interface)  we  can  build  a  common 
standard  for  the  crew  to  "touch."  This  precludes  all  descriptive 
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specifications  that  would  attempt  to  define  a  "standard  set  of 
displays"  or  limit  the  uniqueness  of  a  configuration  that  could 
have  mission  and  crew  tailored  interactions.  These  would  also 
permit  full  tailored  design,  development  and  implementation 
without  loosing  the  "familiar  feeling"  and  common  logical 
interface. 

The  challenge  before  us  is  to  define  and  design  a  function 
interface  standards  for  cockpits  that  represents  the  crew 
"model"of  the  expected  functional  capabilities  and  limitation. 
This  then  permits  the  tailoring  of  the  cockpit  for  accomplishing 
specific  mission  requirements  in  a  manner  which  fully  exploits 
the  alternative  available  without  deviation  from  the  "familiar 
model"  of  the  crew  interface  from  one  aircraft  configuration  to 
the  next. 

Application  of  new  sophisticated  technologies  to  weapon 
system  development  has  led  to  increased  system  capability.  It 
also  has  increased  mission  complexity  and  produced  higher 
workload  levels,  particularly  in  the  cognitive  areas.  Therefore, 
the  emerging  knowledge  based  systems  are  needed  to  help  the  pilot 
cope  with  the  information  overload  with  which  he  must  contend. 

The  introduction  of  these  future  technologies  including  Machine 
Intelligence,  and  Artificial  Intelligence  as  part  of  an  Expert 
System  will  allow  automation  of  a  wider  variety  of  functions.  It 
is  important  to  note,  however,  that  the  problem  of  functional 
differences  could  be  worsened  depending  upon  the  degree  to  which 
systems  designers  embrace  the  opportunities  for  automation 
inherent  in  the  new  techniques. 

In  the  near  future  it  will  likely  be  feasible  and  even 
practical  to  automate  a  wider  variety  of  functions.  However, 
unless  care  is  taken  in  the  design,  the  information  available  to 
the  pilot  could  be  reduced  such  that  he  would  be  taken  out  of  his 
Situational  Awareness.  Both  flight  safety  and  mission 
effectiveness  could  be  adversely  affected. 

This  proposed  effort  would  result  in  a  coherent  plan  to 
apply  automation  prudently  to  weapons  systems.  A  primary  goal 
would  be  to  reduce  the  pilot's  workload  in  high  workload 
situations  to  acceptable  levels  without  sacrificing  his 
Situational  Awareness  and  even  hopefully  enhance  it.  The  product 
of  the  proposed  effort  would  be  a  Standard  Operator  Functional 
Interface  (SOFI) .  The  steps  to  accomplish  a  system 
hardware/software  interface  are: 

a.  Develop  a  list  and  organize  all  currently  documented 
rotary  wing  aircraft  aircrew  functions.  Include  those  functions 
which  could  conceivably  be  allocated  to  the  aircrew. 

b.  Segregate  the  functions  into  groupings  independent  of 
the  aircraft  type  and  mission. 
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c.  Document  current  allocations  (man  and  machine)  and, 
where  possible,  the  rationale  for  such  allocations. 

d.  Modify  the  allocations  based  on  an  analysis  of  human 
interactions  with  predicted  future  technological  innovations. 

The  proposed  allocations  will  embed  machine  tasks  in  the 
operational  context  and  will  use  real  time  decision  aiding 
concepts  to  provide  support  of  the  pilots  Situational  Awareness. 
This  will  result  i  na  draft  SOFI. 

e.  Model  missions  using  current  attentional  demand 
probabilistic  modeling  techniques  will  be  employed  to  provide  a 
reasonable  degree  of  workload,  while  maximizing  the  pilot's 
Situational  Rareness.  This  will  result  in  high  operational 
mission  effectiveness.  This  step  will  be  iterative  in  that  the 
suggested  Standard  Operator  Functional  Interface  will  be 
repeatedly  modified  to  achieve  a  balance  between  acceptable 
workload,  and  optimal  Situational  Awareness  and  Mission 
Effectiveness . 

f.  The  functional  allocation  rationale  and  model  results 
would  be  validated  in  simulator  activities. 

g.  A  roadmap  would  be  developed  which  would  relate  the  SOFI 
to  the  Joint  Integrated  Avionics  Working  Group  (JIAWG)  and  the 
Joint  Services  Review  Committee  (JSRC)  hardware/ software 
developments.  The  roadmap  would  also  include  means  for  evolving 
the  SOFI  as  new  applicable  technologies  become  .available. 

The  product  will  be  a  Standard  Operator  Functional  Interface 
which  would  incorporate  emerging  knowledge  based  technology  but 
at  the  same  time  actively  involve  the  pilot  in  mission 
accomplishment  and  optimize  his  Situational  Awareness.  The 
resulting  standard  interface  would  contribute  to  reduced  training 
costs,  the  promotion  of  an  efficient  system  design  process  and 
enhanced  operational  performance.  The  roadmap  would  be  used  to 
relate  the  SOFI  to  other  DoD  activities  and  to  plan  for 
technology  insertions  as  they  become  available. 

summary.; 

With  the  fast  technological  development  pace  and  the 
progress  being  made  on  new  integrated  avionics  systems,  it  is 
important  to  address  the  above  issues  now.  A  feasible  approach 
has  been  described  which  not  only  considers  application  of  new 
knowledge  based  systems  into  weapons  systems  (new  and  old) ,  but 
it  also  is  complimentary  with  other  ongoing  DoD  standardization 
initiatives.  The  roadmap  would  be  particularly  useful  in 
formulating  a  long  term  investment  strategy. 

I  propose  to  begin  with  an  approximate  4  month  Phase  I 
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effort.  This  would  result  in  a  Program  Plan  to  develop  the 
following: 

a.  Standard  Operator  Functional  Interface  as  described. 

b.  A  description  of  the  application  of  the  SOFI  to  new  and 
inservice  weapons  systems. 

c.  A  plan  to  compliment  other  relevant  DoO  standardization 
activities. 

d.  A  roadmap  for  incorporating  new  technologies  as  they 
become  available. 

Your  views  and  description  of  related  effort  are  most 
welcome  in  helping  to  further  define  the  requirements  and 
products  of  the  effort. 
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Abstract 

It  is  argued  that  the  successful  development  of  applications  using  expert  systems  requires 
the  consideration  of  a  wide  range  of  issues,  both  technical  and  extra- technical.  This  document 
presents  a  framework  intended  to  facilitate  the  consideration  and  addressing  of  what  are  argued 
as  important  issues  in  the  development  of  applications  based  on  “expert  systems”  technology. 


Introduction 

The  Knowledge  Engineering  Group  (KEG)  was  set  up  to  promote  the  use  of  Artificial  Intelligence 
(AI)  and  Expert  Systems  (ES)  within  HP.  KEG  provides  consultancy  and  application  development 
support  to  HP  entities  working  in  the  areas  of  AI  and  expert  systems,  and  pursues  research  goals 
aimed  at  producing  methods  to  support  the  principled  development. of  both  AI  and  Expert  Systems. 
The  rationale  behind  the  promotion  of  this  technology  is  that  both  AI  and  ES  offer  substantial 
potential  for  developing  applications  which  promote  productivity  gains  and  cost  savings  for  the 
user. 

Issues  (or  contributory  factors)  may  be  roughly  partitioned  into  three  areas,  reflecting  the  chrono¬ 
logical  order  in  which  the  issues  generally  present  themselves: 

•  project  initiation  issues 

•  software  engineering  process  issues 

•  domain  analysis  issues 

Recent  commentaries  on  the  reasons  for  failure  of  expert  systems  applications  suggest  that  the 
keystone  reason  for  failure  is  an  insufficient  amount  of  attention  devoted  to  project  initiation  issues, 
resulting  in  misconceptions  of  the  utility/contribution  of  the  systems  subsequently  developed.  Whilst 
expert  systems  technology  has  generated  some  stable  techniques,  the  mere  application  of  those 
techniques  to  arbitrary  domains  is  no  guarantee  of  success.  The  following  discussion  will  attempt 
to  demonstrate  the  reasons  why  a  preliminary  analysis  phase  is  so  important  to  the  success  of  an 
application.  It  should  be  noted  that  the  categorisation  implies  nothing  about  the  relative  importance 
of  the  issues;  as  will  be  argued,  the  issues  are  often  interdependent  and  comparable  in  importance. 
Although  devoting  attention  to  the  resolution  of  non-technical  issues  is  important,  the  balanced 
consideration  of  technical  issues  is  also  a  highly  important  factor  in  the  success  of  an  ES  application. 
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In  this  document,  the  term  “application”  is  taken  to  mean  any  application  of  expert  systems 
technology  to  an  arbitrary  domain.  The  rationale  behind  the  genesis  of  an  ES  applications  project 
may  vary  considerably  with  circumstances.  It  may  be  an  exploratory  venture,  to  assess  the  potential 
contribution  of  the  technology,  or  to  assess  the  tractability  of  the  domain.  Neither  of  these  issues 
are  easy  to  decide  in  vacuo;  an  existing  system  and  the  experience  gained  in  developing  it  provide 
much  of  the  information  required  for  making  such  decisions. 

It  should  also  be  noted  that  the  term  “expert  system”  need  not  necessarily  involve  “Artificial 
Intelligence”  techniques,  sometimes  a  conventional  software  approach  is  appropriate.  If  a  domain 
can  be  mapped  into  a  decision  tree,  then  there  is  no  reason  why  a  system  based  on  such  a  formulation 
of  knowledge  should  not  be  termed  “expert”.  It  does,  after  all,  capture  and  animate  (albeit  in  a 
limited  fashion)  expert  knowledge. 

The  software  engineering  process  issues  are  not  discussed  in  this  document.  There  is  some 
contention  as  to  whether  software  engineering  methodology  can  make  a  significant  contribution  to 
expert  systems  applications  development.  Certainly,  for  “exploratory”  ventures,  it  is  difficult  to  see 
how  a  methodology  could  be  of  assistance,  either  in  specifying  the  functionality  of  the  system  or  in 
implementing  the  code. 

It  appears  that  the  different  methodologies  available  provide  differing  levels  of  contribution  but  it 
has  proved  difficult  to  identify  which  methodologies  provide  the  optimum  contribution  in  a  particular 
set  of  developmental  circumstances.  What  is  clear  is  that  further  analysis  is  required  in  this  area 
and  it  is  one  of  the  KEG’s  objectives  to  attempt  such  an  analysis. 

Project  initiation  issues 

Issues  involved  in  this  area  may  again  be  divided  into  three  categories: 

•  market  opportunity  issues 

•  operational  definition  issues 

•  project  instantiation  issues 

These  issues  are  crucial  in  that  they  help  determine  the  scope  and  range  of  appropriate  effort 
and  resource  expenditure.  There  is  an  analogy  with  stocks  and  shares.  One  can  gamble  for  high 
payback  on  the  futures  markets  (e  g.  currency  speculation),  this  sort  of  venture  is  accompanied  by 
high  risks  of  failure  and  loss.  On  the  other  hand,  one  can  take  a  cautious  approach  and  invest  in 
less  volatile  stock  but  the  payback  is  commensurately  smaller.  It  is  frequently  (but  not  always)  the 
case  that  the  greater  the  potential  rewards,  the  higher  the  likelihood  of  failure,  the  more  secure  the 
return,  the  smaller  the  rewards.  Different  circumstances  provide  different  contexts  for  approaching 
ES  applications  development. 


Market  opportunity  issues 

The  market  opportunity  issues  may  be  subdivided  further  into  issues  of  application  identification 
and  contribution,  both  of  which  are  somewhat  interdependent.  It  is  difficult  to  conceive  of  an 
application  which  makes  a  contribution  but  is  not  used  —  and  it  would  be  a  surprising  case  in 
which  an  application  was  used  extensively  in  internal  business  operations  but  did  not  make  some 
contribution  towards  efficiency  or  cost  savings  benefits. 
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Application  identification  issues 


The  success  or  failure  of  an  expert  systems  application  can  depend  crucially  on  the  identification  of 
an  opportunity  for  the  system’s  use.  This  is  highly  important  for  “planned”  applications,  less  so  for 
exploratory  ventures  —  but  only  if  the  latter  are  to  be  regarded  primarily  as  educational  exercises. 

If  exploratory  ventures  are  intended  to  identify  potential  contributions  from  advanced  software 
techniques  and  to  assess  the  tractability  of  domains,  then  the  investment  of  resources  should  have 
some  chance  of  paying  off  eventually  with  a  useable  —  and  used  system. 

Unused  applications,  unless  undertaken  to  promote  the  growth  of  internal  expertise  and  famil¬ 
iarity  with  the  technology,  show  little  return  on  the  investment  of  resources  that  went  into  their 
development.  Identifying  a  market  opportunity  for  the  application  is  not  an  easy  task  and  a  sub¬ 
stantial  amount  of  effort  should  be  devoted  to  this  —  as  much  (and  possibly  more)  as  would  be 
devoted  to  a  conventional  software  project  of  similar  adventurousness.  It  is  essentially  an  invest¬ 
ment  decision  and  should  be  treated  as  such. 


Application  contribution  issues 

The  identification  of  the  market  or  opportunity  for  an  expert  system  should  be  accompanied  by  a 
realistic  assessment  of  the  potential  contribution  of  the  application. 

Potential  contribution,  however,  is  rarely  a  clear-cut  issue:  as  with  many  situations  it  is  often 
the  case  that  the  80-20  rule  holds  (80%  of  the  work  can  be  done  with  20%  of  the  resources).  The 
optimal  strategy  —  if  the  rule  holds  —  is  to  identify  the  80%  of  the  application  domain  which  can 
be  tackled  with  an  application  embodying  20%  of  the  resources.  This  implies  (and  is  often  the  case) 
that  the  applications  system  need  not  be  an  “elephant”  (and  perhaps  not  even  a  “buffalo”)  in  order 
to  make  a  substantial  contribution. 

It  is  important  to  analyse  carefully  the  application  domain  in  order  to  identify  what  would 
be  a  “reasonable”  contribution  from  an  expert  systems  application.  By  doing  so,  developers  can 
concentrate  on  providing  solutions  to  a  focussed  set  of  problems  and  thus  have  a  much  better  chance 
of  developing  a  system  which  is  capable  of  making  a  significant  contribution. 

Operational  definition  issues 


Developers  should  be  clear  about  the  objectives  for  the  application  development,  whether  it  be  a 
full  application  or  a  cautious  exploratory  venture.  Due  to  the  novelty  of  the  techniques  to  many 
engineers,  the  power  (and  complexity)  of  the  techniques  can  seduce  developers  into  straying  off  the 
developmental  path.  It  is  vital  to  have  a  clear  idea  of  the  eventual  functionality  of  the  applica¬ 
tions  system;  without  a  detailed  specification  (often  not  possible  for  exploratory  ventures)  it  is  all 
too  possible  to  be  sidetracked  into  devoting  scarce  resources  towards  addressing  non-central  (but 
nevertheless,  “interesting”)  issues. 

As  with  any  project,  there  should  be  an  operational  definition  of  success.  This  is  particularly 
important  for  exploratory  ventures  where  the  eventual  size  and  scope  of  the  system  is  not  properly 
estimable  until  more  about  the  domain  is  known.  In  many  cases,  a  prototype  system  is  an  appropriate 
result  but  there  should  be  some  objective,  decideable  criteria  of  success. 

Depending  on  the  tractability  (or  otherwise)  of  the  domain,  a  prototype  system  which  could 
handle  successfully  a  limited  range  of  problems  of  an  intermediate  level  of  difficulty  would  be  a 
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reasonable  criterion  of  success.  Some  domains  are  more  difficult  to  formalise  than  others  and  the 
system  developers  will  usually  have  a  good  idea  of  what  constitutes  a  “limited  range  of  problems  of 
an  intermediate  level  of  difficulty”. 

It  is  important  not  to  over-enthuse  about  the  eventual  functionality  of  applications  systems.  In 
the  U.S.,  it  is  the  considered  opinion  of  many  commentators  that  one  of  the  main  reasons  for  the 
U.S.  retrenchment  in  investment  in  AI  is  a  general  disillusionment  brought  about  by  vendors’  and 
developers’  non-fulfilment  of  earlier  over-optimistic  claims.  However,  it  is  important  to  bear  in  mind 
that  focussed  applications  of  advanced  software  technology  are  capable  of  providing  a  substantial 
payoff. 

Project  instantiation  issues 

These  issues  are  generally  more  technical  in  nature  than  the  strategic  issues  discussed  above,  however, 
these  too  are  central  to  the  technical  success  of  the  application  development. 

•  resource  constraints 

•  prototype  issues 

•  access  to  domain  expertise 

•  access  to  user  population 

Careful  attention  to  the  resolution  of  these  issues  acts  to  promote  the  establishment  of  a  favourable 
grounding  from  which  a  development  may  begin. 


Resource  constraints 

The  objectives  of  an  application  development  should  be  set  with  reference  to  the  constraints  on 
available  resources.  This  may  seem  a  self-evident  assertion  but  unfamiliarity  with  the  capabilities 
of  the  technology  can  lead  to  expectations  of  functionality  which  are  unrealistic  with  respect  to 
the  amount  of  resources  allocated.  In  addition,  the  realisation  of  differing  degrees  and  areas  of 
functionality  results  in  markedly  different  demands  on  resources. 

It  is  difficult  to  provide  a  precise  analysis  of  this  particular  aspect  of  development  for  two  reasons; 
firstly,  much  depends  on  the  type  and  scope  of  the  development  being  attempted,  secondly,  there 
are  subtle  interactions  between  various  components  and  techniques  available  for  inclusion  in  an 
application  development. 

From  a  preliminary  (qualitative)  analysis  of  these  interactions,  this  particular  issue  appears  to 
present  developers  with  considerable  problems.  The  interactions  are  many  and  complex;  some  care 
is  necessary  to  ensure  that  the  core  problems  of  the  development  issues  axe  being  tackled.  It  is 
our  experience  that  application  developments  can  be  made  overly  difficult  (and  costly)  through 
the  inclusion  of  peripheral  features,  e.g.  “explanation”  and  “user-friendly  interface”,  which  are  not 
central  to  the  functionality  of  the  system.  This  can  lead  to  situations  in  which  not  only  are  the 
wrong  problems  solved,  but  also  the  core  problems  (which  act  as  the  rationale  for  the  development) 
remain  unaddressed  through  consequent  lack  of  resources  (the  latter  having  been  consumed  by  the 
solution  of  the  wrong  problems). 
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Prototype  issues 

Many  applications  developments  require  the  development  of  a  prototype  system  for  preliminary 
evaluation  purposes.  It  is  not  often  possible  to  specify  adequately  the  functionality  of  the  final 
system,  sometimes  it  is  undesirable  to  do  so,  particularly  in  the  case  of  incremental  development 
techniques,  where  each  stage  has  a  major  effect  on  determining  the  direction  and  scope  of  the  next 
phase. 

Given  the  subtlety  and  complexity  of  the  interaction  between  the  elements  and  features  of  an 
expert  system  (such  as  that  that  exists  between  providing  a  multiple  solution  facility  and  an  expla¬ 
nation  facility),  it  is  often  not  possible  to  predict  satisfactorily  the  effects  of  such  interactions  upon 
the  tractability  of  the  system  and  several  different  implementation  paths  may  need  to  be  explored  in 
order  to  achieve  the  design  goals  of  the  system.  In  consequence,  it  is  frequently  desirable  to  discard 
a  prototype  and  start  again,  from  a  position  of  superior  knowledge  and  experience. 

The  inappropriate  retention  of  a  prototype  can  constrain  seriously  the  eventual  functionality  of 
an  application  development  —  sufficiently  for  the  application  to  fail  to  meet  the  agreed  criteria.  A 
more  frequent  result  is  increased  difficulty  of  integration  of  required  features  and  elements,  as  the 
aforementioned  interactions  generally  demand  careful  architectural  planning. 


Access  to  domain  expertise 

It  is  almost  tautological  to  observe  that  in  order  to  develop  successfully  an  expert  system  application, 
the  developers  should  have  access  to  domain  expertise.  However,  there  are  normally  several  pos¬ 
sible  sources  of  domain  expertise,  some  more  readily  available  than  others.  Domain  expertise  may 
be  either  “decontextualised”  (theories,  rules  of  working  practice  etc)  or  “contextual”  (case-based 
heuristics,  “on-the-job”  learning,  etc).  Decontextualised  domain  expertise  is  often  made  available 
in  manuals  or  texts  and  is  largely  easy  to  access.  Contextualised  knowledge  is  rarely  set  down  and 
more  often  available  only  through  direct  access  to  the  experts  who  have  this  expertise. 

Experts  are  nearly  always  in  demand  —  their  knowledge  is  frequently  a  scarce  resource  and  it 
can  be  difficult  for  systems  developers  to  gain  sufficient  access. 


Access  to  user  population 

The  development  of  an  expert  system  without  user  input  to  the  design  process  can  be  disastrous. 
Whilst  it  may  be  the  case  that  users’  ability  to  visualise  the  eventual  system  may  be  limited,  the 
careful  consideration  of  users’  needs  can  dramatically  improve  the  useability  of  an  application. 

A  subsequent  section  of  this  document  discusses  the  technical  issues  involved  in  considering  this 
particular  aspect  of  applications  development.  It  is  important  that  the  set  of  eventual  users  are 
identified,  there  is  often  a  substantial  difference  in  requirements  between  sets  of  potential  users, 
which  should  affect  fundamentally  the  design  of  the  system. 


Domain  analysis  issues 

In  order  to  separate  more  conveniently  the  technical  issues  of  domain  analysis,  they  have  been 
categorised  according  to  three  dimensions  and  a  framework  produced  accordingly.  This  framework 
provides  the  major  technical  thrust  of  this  document. 
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Firstly  the  dimensions  of  the  framework  will  be  discussed  and  then  each  section  of  the  framework 
will  be  separately  addressed.  For  the  preliminary  version  of  this  document,  sections  will  be  little 
more  than  a  rough  outline  of  the  scope  of  the  area,  accompanied  by  a  description  of  existing  and 
relevant  work  in  the  field.  It  is  intended  that  eventually,  each  of  the  sections  will  be  completed  in 
some  detail. 


Framework  dimensions 

The  vertical  dimension  attempts  to  capture  an  intuitive  difference  between  what  one  may  call  the 
“informational”  and  “procedural”  aspects  of  the  domain.  There  are  aspects  to  experts’  activities 
(specifically  “consulting”)  which  are  rarely  addressed  when  considering  domain  knowledge  and  ex¬ 
pertise.  These  aspects  are  discussed  in  more  detail  in  a  subsequent  section  where  it  is  argued 
that  these  additional  non-domain-specific  activities  demand  careful  consideration.  Admittedly,  the 
dichotomy  presented  here  is  an  over-simplification  of  a  more  complex  dimension,  however  a  simplify¬ 
ing  differentiation  does  allow  of  a  certain  utility  for  the  purposes  of  expressing  interrelated  technical 
issues  within  the  framework  proposed. 

The  horizontal  dimension  expresses  the  familiar  “expert(s)”  vs.  “user(s)”  distinction.  Once 
again  this  dichotomisation  of  a  complex  dimension  is  an  oversimplification  in  the  interests  of  clarity 
of  presentation. 

The  third  (“before”  vs.  “after”)  dimension  represents  a  temporal  differentiation  which  pro¬ 
motes  consideration  of  the  “current”  human-mediated  system,  as  well  as  the  issues  of  the  proposed 
computer-mediated  system.  Some  recent  commentary  argues  that  there  are  many  non-technical  fac¬ 
tors  in  play  in  human-mediated  systems  which  have  an  important  role  in  the  way  the  system  works. 
Encouraging  the  developers  to  look  for  and  examine  these  non-technical  factors  helps  them  to  create 
an  application  which  fits  more  neatly  into  the  target  organisational  system..  The  word  “system”  here 
includes  the  experts,  the  users,  information  provision/usage,  etc.  Essentially,  this  dimension  allows 
of  the  contrasting  of  the  current  (human-mediated)  system  with  the  proposed  (computer-mediated) 
system. 

The  “front"  four  topics  (la,  lb,  lc  and  Id)  can  be  viewed  as  representing  the  issues  ivolved 
in  characterising  the  “current”  human-mediated  system,  the  “back”  four  boxes  can  be  viewed  as 
representing  issues  involved  in  creating  the  actual  application.  Movement  from  “front”  to  “back” 
represents  the  process  of  implementation.  As  the  KEG  is  interested  in  producing  methods  to  support 
the  principled  development  of  both  AI  and  Expert  Systems,  this  process  of  implementation  is  one 
of  the  main  spheres  of  interest.  The  specification  of  how  one  might  move  (from  the  characterisa¬ 
tion  contained  in  the  “front”  box  to  the  implementation  techniques  embodied  in  the  corresponding 
“back”  box)  would  be  equivalent  to  a  methodology  for  the  building  of  an  expert  system  application. 
However,  before  such  a  specification  can  be  attempted,  the  issues  embodied  in  the  topics  need  to  be 
instantiated  in  some  detail. 


la:  Domain  knowledge  characterisation 

The  effective  representation  of  domain  knowledge  is  generally  considered  to  be  a  major  element  of 
success  for  a  KBS,  different  types  of  domain  knowledge  hold  different  implications  for  the  selection 
of  knowledge  representation  schemes.  In  addition,  the  type  of  domain  knowledge  has  fundamental 
effects  on  problem-solving. 

The  prescriptions  presented  by  Stefik  (Stefik,  et  a).,  1982)  remain  valid  ten  years  on  and  still 
provide  a  valuable  way  of  characterising  domain  knowledge.  Stefik  distinguishes  different  types  of 
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Figure  1:  Framework  of  technical  issues 
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domain  knowledge  via  constraints  that  the  former  levy  upon  the  type  of  problem-solving  which  can 
be  performed: 


•  size  of  solution  space 

•  stability  of  data 

•  reliability  of  data 

These  dimensions  provide  only  a  partial  characterisation  of  domain  knowledge.  From  cognitive 
psychology,  Guilford’s  (Guilford,  1954)  model  of  the  intellect  proposes  other,  more  general  attributes: 

•  figural 

•  semantic 

•  symbolic 

•  behavioural 

Although  this  is  a  more  general  descriptive  scheme,  it  does  offer  some  useful  characterisation 
—  reasoning  with  figural  or  behavioural  knowledge  is  somewhat  beyond  the  limits  of  robust  KBS 
technology  and  is  currently  a  research  issue.  Whilst  this  may  be  quite  well  known  to  experienced 
practitioners,  it  is  a  useful  datum  to  those  who  are  less  familiar  with  the  limits  of  the  technology. 

The  issue  of  the  structure  of  knowledge  has  been  addressed  in  other  cognitively-motivated  work. 
Durding,  et.  al  (Durding,  et.  al.  1977)  have  investigated  preferred  knowledge  structures  for  a 
number  of  tasks.  The  structures  used  in  the  empirical  test  included: 

•  hierarchy 

•  network 

•  list 

•  categorized  list 

•  table 

•  categorized  table 

•  incomplete  table 

•  categorized  incomplete  table 

The  results  of  the  work  demonstrated  the  desirability  of  a  second  order  isomorphism  between  the 
user’s  internal  representation,  the  retrieval  system’s  internal  representation  and  the  external  data 
object  represented.  In  essence,  to  facilitate  processing,  it  is  important  to  preserve  structure. 
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lb:  Knowledge  representation  scheme 

The  choice  of  a  computer-mediated  knowledge  representation  scheme  in  which  to  model  the  human- 
mediated  domain  knowledge  is  often  a  critical  technical  issue.  Cognitively-motivated  research  indi¬ 
cates  that  problem-solving  may  be  severely  impaired  by  inappropriate  representation  schemes. 

Apart  from  the  above  fairly  crucial  consideration,  there  are  other  important  implications  in  co¬ 
operative  problem  solving  paradigms  and  where  reasoning  support  is  required.  It  is  necessary  in 
both  these  cases  for  the  user  to  he  able  to  develop  an  understanding  of  the  way  the  system  conducts 
the  problem  solving.  The  development  of  this  understanding  is  heavily  dependent  on  the  degree  of 
match  between  the  knowledge  structures  held  respectively  by  the  system  and  the  user. 

The  interaction  of  several  contributory  factors  makes  the  choice  rather  complex.  The  notion  • 
of  using  an  intermediate,  abstract  representation  has  been  recommended  by  several  commentators 
as  a  means  by  which  a  better  understanding  of  the  interaction  may  be  achieved  by  the  develop¬ 
ers,  thus  enhancing  the  liklihood  of  selecting  the  most  appropriate  computer-mediated  knowledge 
representation. 

The  recently-formulated  KADS  KBS  development  methodology  (Hayward,  et.al,  1987)  proposes 
a  candidate  intermediate  representation  in  the  form  of  a  declarative  description  of  the  represen¬ 
tation  of  descriptive  definitions  of  domain  terms,  domain  objects  and  their  relationships  to  each 
other  and  suggests  that  this  representation  can  be  considered  as  independent  of  the  domain  tasks. 
The  structural  features  of  the  descriptions  are  preserved  in  the  intermediate  representation  and 
implementation  decisions  can  be  postponed  until  a  satisfactory  model  of  the  domain  is  developed. 

This  essentially  static  model  is  then  used  as  input  and  output  parameters  to  a  task-dependent 
model  of  domain  problem-solving  expertise.  Severed  experiments  have  been  conducted  using  this 
methodology  and  favourable  reports  of  the  technique  have  been  received. 


2a:  Expertise  classification 

In  this  framework,  the  distinction  between  “domain  knowledge”  and  “expertise”  reflects  more  a 
distinction  between  “knowing  what”  and  “knowing  how” ;  issues  which  are  at  least  separable,  if  not 
independent.  Whether  “expertise”  exists  independently  of  “domain  knowledge”  is  not  yet  clear  and 
evading  the  issue  entirely,  the  rest  of  this  section  will  equate  “expertise”  with  “reasoning” . 

Having  a  descriptive  definition  of  domain  terms,  objects  and  relationships  is  a  necessary  but  not 
sufficient  condition  for  the  demonstration  of  expertise.  It  is  also  necessary  to  be  able  to  manipulate 
and  reason  with  this  knowledge  in  some  fashion,  usually  by  making  inferences,  performing  problem¬ 
solving,  etc. 

The  type  of  reasoning  displayed  by  the  expert  in  the  human-mediated  system  has  profound 
implications  for  the  problem-solving  architecture  of  the  computer-mediated  system.  Some  general, 
abstract  types  of  reasoning  have  been  identified: 

•  goal-directed  reasoning 

•  data-directed  reasoning 

•  causal  reasoning/reasoning  from  first  principles 

Goal-directed  reasoning  involves  the  matching  of  hypotheses  to  the  data,  a  kind  of  iterative 
“best-guess”  process.  Datardirected  reasoning  involves  working  forwards  logically  from  the  data 
given  (usually  via  the  application  of  rules).  Causal  reasoning  involves  developing  causal  explanations 


83 


of  the  data,  working  from  first  principles.  Generally,  causal  reasoning  expertise  is  beyond  the  scope 
of  robust  KBS  technology  and  largely  remains  in  the  province  of  AI  research. 

Because  of  the  impact  that  these  different  types  of  expertise  have  on  the  KBS  architecture,  the 
most  useful  detailed  classification  schemes  are  the  problem  typologies  which  have  arisen  out  of  work 
in  KBS.  It  is  mainly  by  these  problem  typologies  that  it  is  pcssible  to  provide  useful  characterisations 
of  different  types  of  reasoning  tasks. 


2b:  Problem-solving  typology 

The  KADS  KBS  development  methodology  provides  a  problem  typology  which  is  used  as  a  library 
from  which  the  developer  draws  a  problem-solving  template  appropriate  for  the  domain  reasoning 
task.  The  KADS  problem  typology  includes  analysis,  modification  and  synthesis  tasks,  examples  of 
which  are  shown  below: 

•  modelling 

•  planning 

•  identification 

•  fault  diagnosis 

•  heuristic  classification 

•  causal  tracing 

•  prediction  of  behaviour 

•  repair 

•  configuration 

It  is  of  some  concern  that  this  formulation  lacks  both  a  robust  theoretical  underpinning  and  em¬ 
pirical  support.  KADS  are  currently  seeking  a  formal  specification  of  these  tasks  and  it  is  uncertain 
whether  formal  techniques  are  sufficiently  expressive  to  produce  useful  specifications.  The  formal 
description  of  behaviour  is  a  recognised  bete  noir. 


3a:  Role  of  expertise  in  performance  of  user’s  task 

It  is  important  to  consider  the  importance  of  the  expertise  to  the  user.  There  are  profound  im¬ 
plications  for  the  necessity/desirability  of  reasoning  support  or  explanation,  both  of  which  have 
subsequent  implications  for  the  choice  of  problem-solving  paradigm  and  knowledge  representation 
scheme. 

If  the  expertise  is  a  central  component  in  the  user’s  performance  of  tasks,  then  it  is  likely  that 
reasoning  support  will  be  required.  More  obviously,  if  there  are  critical  decisions  (financial,  medical 
treatment)  to  be  made  on  the  basis  of  the  problem  solutions  provided  by  the  system,  then  support 
for  the  reasoned  solution  will  be  (understandably)  demanded  by  the  user. 

On  the  other  hand,  providing  unnecessary  reasoning  support  consumes  resources  unnecessarily. 
If  the  expertise  plays  only  peripheral  role  in  the  execution  of  the  user’s  task,  say  as  a  minor  input 
parameter,  then  merely  providing  the  solution  (in  the  appropriate  structural  form)  will  suffice. 
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There  appear  to  be  two  main  components  of  this  issue  —  whether  the  in*  /action  is  an  “oracular” 
vs.  “consultative”  type  and  whether  the  user  is  expected  to  take  an  active  role  in  the  problem-solving 
or  not.  Ffom  a  pragmatic  viewpoint,  an  oracular  interaction,  whereby  an  expert  merely  delivers  a 
judgement,  places  fewer  demands  upon  the  system  designer  than  does  a  consultative  interaction. 

Results  from  empirical  studies  tend  to  resist  generalisation  as  subjects  are  usually  students  and 
must  be  considered  as  atypical  users.  However,  as  with  many  issues  in  HC1,  the  notions  of  “models  of 
users”  and  “users’  models”  play  a  large  part  in  developing  an  understanding  of  interactions  between 
user  and  expert. 

A  robust  cognitive  theory  of  models  of  users  and  users’  models  has  yet  to  be  developed,  although 
both  ES  applications  development  and  conventional  software  applications  development  both  suffer 
from  this  same  problem.  With  regard  to  the  style  and  content  of  the  user/expert  interaction,  some 
limited  contribution  from  the  discipline  of  social  psychology  should  be  acknowledged. 

Dramaturgical  theory  provide  the  notion  of  “altercasting” ,  which  is  the  notion  of  “taking  the 
role  of  the  other”  and  its  operation  can  be  identified  in  user-expert  interactions. 

When  a  computer  user  consults  a  systems  advisor  and  asks  (for  example)  for  advice  on  how  to 
print  a  text  file,  the  advisor  has  two  choices: 

1.  to  provide  the  user  with  advice  for  solving  the  particular  problem  encountered 

2.  to  provide  advice  for  solving  a  class  of  problems  (including  the  particular  problem  encountered). 

In  order  to  decide  which  of  the  two  options  to  take,  the  advisor  has  to  consider  the  user’s 
objectives  in  seeking  advice.  By  taking  the  role  of  the  other,  the  adviser  could  reason  (for  example) 
that  a  frequent  user  of  the  system  should  be  provided  with  a  more  complex  general  solution,  being 
quite  likely  to  be  encounter  associated  printing  problems  as  well  as  possibly  being  interested  in 
gaining  mastery  of  the  equipment.  On  the  other  hand,  with  an  infrequent  user,  a  suitable  incantation 
could  be  provided  on  the  basis  that  they  are  less  likely  to  require  the  more  complex  general  solution 
and  may  not  be  so  interested  in  gaining  mastdry  of  the  equipment". 

The  notion  of  altercasting  provides  a  useful  way  of  characterising  the  extent  to  which  the  expert 
is  required  to  develop  models  of  the  users’  requirements  —  and  of  characterising  users  potential 
requirements.  Users  who  are  pressed  for  time  or  who  have  more  prosaic  attitudes  towards  computers 
are  more  likely  to  require  specific  rather  than  general  solutions. 

It  is  worth  noting  that  successful  altercasting  requires  the  altercaster  to  have  reasonably  accurate 
insights  into  the  user’s  objectives  —  i.e.  to  have  some  understanding  of  the  user’s  tasks  and  priorities. 


3b:  System  information  output  specification 

The  development  of  an  understanding  of  the  role  of  the  expertise  in  the  performance  of  the  user’s 
tasks  will  assist  the  developers  in  understanding  the  implications  for  the  output  from  the  application. 

The  oracular  style  of  interaction  is  more  likely  to  be  appropriate  for  smaller  syste.ns,  frequently 
based  on  decision-tree  animation.  The  availability  of  comparatively  cheap  ES  shells  which  constrain 
the  developer  to  simple  decision  trees  promotes  an  oracle-style  interaction,  where  system  works 
through  the  decision  tree  as  the  user  inputs  the  data,  providing  a  canonical  answer  at  the  end  of  the 
interaction. 

Such  shells  —  and  the  systems  developed  in  them  —  typically  do  net  provide  dynamic  explana¬ 
tions  of  reasoning;  reasoning  support  is  usually  provided  at  data  entry  time  and  is  normally  confined 
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to  explanations  of  why  the  system  requires  some  piece  of  data  and  is  based  on  the  current  position 
in  the  decision  tree. 


4a:  Description  of  user’s  tasks 

Functionality  is  an  important  factor  in  the  success  of  any  software  application.  In  conventional 
software  engineering,  system  functionality  is  addressed  during  the  systems  analysis  phase  of  the 
development  lifecycle.  In  the  case  of  ES  applications,  particularly  small  applications  developed 
within  a  shell,  it  is  possible  to  avoid  completely  the  direct  addressing  of  this  issue.  In  consequence, 
it  is  all  too  easy  to  develop  systems  with  inappropriate  or  inadequate  functionality.  With  larger 
systems  is  also  all  too  easy  to  concentrate  on  the  solution  of  technical  problems  at  the  expense  of 
addressing  the  issue  of  functionality. 

Although  the  subject  of  “tasks”  has  been  of  interest  to  workers  in  the  KBS  field,  the  orientation 
taken  is  primarily  toward  mapping  generic  tasks  into  a  problem-solving  typology  or,  alternatively 
to  attempt  to  provide  a  formal  notation  for  describing  tasks. 

There  is  a  need  for  a  descriptive  notation  for  tasks,  but  there  is  also  a  requirement  that  a  task 
description  needs  to  be  understandable  by  the  user  in  order  for  feedback  to  take  place.  The  use 
of  a  problem-solving  typology  or  a  formal  notation  is  quite  likely  to  present  a  barrier  to  the  user’s 
provision  of  feedback. 


4b:  System  usage  profile 

In  the  domain  of  KBS  applications  it  is  particularly  important  to  develop  a  good  understanding  of 
what  tasks  the  user  actually  performs.  This  will  assist  the  development  of  a  correlational  under¬ 
standing  of  what  would  constitute  an  adequate  and  appropriate  scope  and  range  of  functionality  of 
the  intended  application. 

It  has  been  observed  that  human-mediated  systems  have  a  high  bandwidth  of  communications 
between  processes  and  that  some  of  this  bandwidth  is  carried  in  the  socio-political  parts  of  the 
system.  When  developing  a  computer-mediated  system  for  introduction  into  the  milieu  of  human 
affairs  it  is  important  to  recognise  that  artefactual  systems  need  to  be  tailored  carefully  if  they 
are  to  augment  and  not  disrupt  the  flow  of  communications  and  processes,  this  principle  is  doubly 
important  in  information-technology  applications. 

Attempting  to  understand  the  systems  in  the  world  with  which  we  interact  is  an  inherent  facet  of 
the  human  condition.  It  is  impossible  to  prevent  people  from  attempting  to  develop  their  own  models 
of  the  systems  with  which  they  interact.  It  is  entirely  possible  and  in  fact,  usually  the  case,  that  this 
factor  leads  to  changes  in  the  processes  embodied  in  the  remaining  human-mediated  parts  of  the 
system  For  example,  the  majority  of  KBS  applications  can  be  (ab)used  for  educational  purposes, 
whether  the  developers  intended  it  or  not.  This  can  have  effects  on  the  perceived  functionality  of 
the  application  and  also  affect  the  success  of  its  deployment. 
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REQUIREMENTS  ANALYSIS  FOR  PILOT  DISPLAYS 

Jeremy  Clare 

Cambridge  Consultants  Ltd  UK 


1  Introduction 


The  design  of  interfaces  between  pilot  and  systems  continues  to  be  a  difficult  and  complex 
activity.  One  of  the  major  problems  in  designing  the  interface  is  the  definition  of  the 
information  needs  of  the  pilot.  This  problem  is  at  its  worst  in  a  novel  application  of 
which  there  is  no  significant  operational  experience.  The  development  of  systems  based 
on  IKBS  technology  includes  many  such  applications.  These  systems  will  change  the  way 
in  which  the  pilot  interacts  with  his  systems,  and  it  is  a  basic  assumption  that  a  degree  of 
decision  making  will  be  shared  between  the  pilot  and  the  system.  It  is  then  critical  that 
the  pilot  is  able  to  undeutand  what  the  system  is  attempting  to  convey  to  him. 

Little  research  has  been  done  on  developing  methods  and  techniques  which  will  allow  the 
effective  design  of  real  time  user  interfaces  for  novel  applications.  The  critical  issues  in 
designing  the  interface  are  to  ensure  that: 

a.  Sufficient  information  is  available  for  each  step  in  the  decision  sequence. 

b.  The  information  is  accessible  within  the  time  available  for  the  decision  step. 

c.  The  information  is  presented  within  the  context  of  the  overall  task  structure. 

Most  designers  of  interfaces  would  claim  that  this  is  what  they  set  out  to  do.  However 
merely  displaying  information  does  not  ensure  that  the  pilot  is  able  to  access  the 
information.  The  information  displayed  must  be  such  that  it  can  be  absorbed  by  the  pilot 
within  the  time  available.  This  means  that  he  cannot  afford  to  spend  time  searching  large 
arrays  of  data  to  locate  the  information  he  needs. 

The  area  which  causes  most  problems  is  in  the  analysis  of  the  requirement.  The  normal 
approach  is  to  consider  the  system  as  excluding  the  human  component.  Thus  the  analysis 
is  conducted  with  respect  to  the  needs  of  the  pilot,  this  assumes  that  the  tasks  carried  out 
by  the  pilot  will  be  the  same  for  the  new  system  as  they  are  in  the  current  system.  Quite 
separately  there  may  be  an  activity  to  define  the  pilot  task  breakdown,  while  assuming  a 
specific  instance  of  the  current  system. 

These  two  activities  miss  the  fundamental  point.  In  an  aircraft  we  have  a  complete  system 
which  includes  airframe,  weapons,  sensors,  computers  and  a  pilot,  i.e.  the  pilot  is  part  of 
the  complete  system.  An  approach  that  deals  with  this  problem  is  the  use  of  a 
requirements  specification  for  a  total  system  which  includes  the  pilot  as  a  processing 
element  as  well  a  the  computer. 


2  The  Aircraft  as  a  Total  System 

If  we  are  to  regard  the  aircraft  as  a  total  system,  then  we  must  take  an  integrated  systems 
view.  We  can  regard  the  system  as  a  set  of  interconnected  processes  which  execute  a 
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defined  function.  Such  a  view  would  represent  a  classic  engineering  view.  However, 
once  we  start  to  include  the  man  in  the  system  we  have  to  consider  it  as  a  socio-technical 
system.  An  important  characteristic  of  such  systems  is  that  they  have  a  purpose.  That 
purpose  is  supplied  by  the  human  component  of  the  system.  In  fact,  all  systems  have  a 
purpose,  however,  in  many  cases  that  purpose  only  exists  as  a  set  of  concepts  developed 
by  the  designer  and  a  set  of  uses  discovered  by  the  user. 

In  order  to  understand  a  socio-technical  system  it  then  becomes  necessary  to  understand 
the  various  goals  that  the  system  will  attempt  to  satisfy.  These  goals  can  then  be  mapped 
to  the  functions  performed  by  the  system,  which  can  in  turn  be  mapped  to  the  process 
which  will  execute  them.  A  critical  part  of  the  analysis  of  socio-technical  systems  is  that 
the  selection  of  processes  to  carry  out  functions  is  carried  out  at  a  later  stage  of  the 
analysis.  In  some  systems,  such  as  we  may  consider  for  future  aircraft,  the  allocation  of 
processes  may  be  carried  out  in  operation.  The  critical  point  here  is  to  recognise  that 
these  processes  include  the  pilot  as  a  processor. 

If  we  consider  the  system  as  attempting  to  satisfy  a  set  of  goals  then  we  need  to  make 
careful  analysis  of  those  goals  (Harris  and  Barnard  1984).  The  first  aspect  to  recognise  is 
that  the  various  goals  will  not  all  be  compatible  so  if  we  consider  a  ground  attack  aircraft 
in  the  role  of  battlefield  support,  then  its  goals  will  include  success  in  engagement  of 
targets,  success  in  avoiding  threats  and  success  in  maintaining  a  safe  flight  envelope. 
Such  goals  are  clearly  in  conflict  since  greatest  success  in  engagement  is  achieved  by 
flying  high  and  slow  which  maximises  the  exposure  to  threats.  In  Figure  1  this  goal 
hierarchy  is  decomposed  to  show  some  of  the  sub  goals. 


f  igure  1  Decomposed  Goal  Hierarchy 


As  we  examine  the  goal  decomposition  we  can  see  that  some  subgoals  are  executed 
sequentially  while  others  are  executed  concurrently.  Thus,  in  developing  a  set  of  functions 
that  allow  these  goals  to  be  achieved,  it  is  necessary  to  define  some  functions  that  balance 
the  resources  devoted  to  the  achievement  of  conflicting  goals.  In  the  Pilot’s  Associate 
Model  this  set  of  functions  are  included  in  the  Exec  Manager.  It  is  an  interesting 
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component  of  the  Pilot’s  Associate  programme  that  it  is  recognised  that  some  of  these 
balancing  functions,  if  not  all,  need  to  be  transferred  from  the  pilot  to  the  AI  system. 

The  decomposed  goals  then  need  to  be  mapped  to  a  set  of  functions,  with  defined  data 
flows  that  are  needed  to  support  them.  To  do  this  there  is  a  need  to  develop  suitable 
models  of  the  system  functionality.  In  Figure  2  (page  10),  the  basic  model  used  for  the 
Pilot’s  Associate  programme  is  shown,  this  assumes  a  very  high  interconnection  between 
the  core  functions.  This  view  assumes  significant  complexity  of  data  flows  between 
functions  and  the  control  that  must  be  applied  via  the  Exec  Manager  Function.  This 
particular  view  of  the  system  separates  the  pilot  from  the  computer  based  system,  and  has 
thus  carried  out  an  allocation  of  function  between  the  human  and  machine  processors. 

An  alternative  model  of  the  functional  decomposition  of  the  systems  can  be  developed 
using  a  basic  C3I  control  model  approach  (Morgan  1982).  This  model  assumes  that  there 
is  a  hierarchy  of  functions,  in  particular  with  respect  to  planning,  as  shown  in  Figure  3. 


Figure  3  Generalised  Control  Model 
In  this  model  the  processes  are  as  follows: 

Perception  -  interpretation  of  incoming  signals  to  produce  a  view  of  various 
systems.  This  process  includes  data  fusion. 

Assessment  -  the  interpretation  of  the  fused  data  to  develop  an  assessed  view  of 
the  world  by  adding  to  it  intelligence  and  other  data.  This  includes  situation 
assessment  and  systems  monitoring. 

Decision  -  the  evaluation  of  the  assessed  view  in  the  context  of  plans  to  select 
appropriate  action. 

Planning  -  the  development  of  a  local  plan  in  the  context  of  high  level  plans  and 
the  recent  situation.  This  process  is  cycled  at  a  slower  rate  than  the  other 
processes.  Classical  control  theory  would  suggest  that  the  ratio  should  be  about 
10  between  the  planning  cycle  and  the  execution  cycle. 

Action  -  the  execution  and  monitoring  of  the  chosen  responses.  This  includes 
both  the  selection  of  operating  models  and  the  direct  control  of  some  systems. 
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This  general  view  can  be  mapped  to  the  aircraft  as  shown  in  Figure  4.  In  this  view,  data 
flow  is  shown  as  continuous  line  and  control  flow  as  a  broken  line. 


Figure  4  Control  Model  for  Ground  Attack 

Whichever  model  of  processing  that  we  use  to  describe  the  aircraft  system  we  are  then 
presented  with  the  key  problem  of  defining  the  methods  of  interaction  between  the  pilot 
and  the  other  aircraft  system.  This  then  leads  to  the  problem  defining;  the  requirement  for 
the  pilot  displays  and  controls.  (Displays  include  auditory  and  tactile  communications  as 
well  as  visual).  The  next  section  discusses  an  approach  for  pilot  display  requirements 
analysis. 


3  DISPLAY  REQUIREMENTS  ANALYSIS 

The  principal  issue  for  the  pilot’s  display  system  is  to  ensure  that  he  is  able  to  access  the 
appropriate  data  for  his  current  task.  As  we  have  seen  from  the  discussion  above, 
definition  of  the  current  task  is  a  complex  problem  since  he  will  be  attempting  to  satisfy 
more  than  one  goal  at  any  moment  in  time.  In  the  ground  attack  example  discussed  above 
we  identify  three  processes  in  which  he  must  have  an  involvement,  Figure  5.  In  fact, 
there  has  to  be  a  fourth  process  which  is  the  management  of  the  amount  of  effort  given  to 
each  process  and  the  setting  of  their  priorities.  The  display  systems  must  provide  him 
with  sufficient  information  for  him  to  meet  these  goals.  This  need  would  seem  relatively 
straightforward  if  the  data  transfer  rate  between  the  displays  and  the  man  were  high. 
However,  individuals  are  only  able  to  take  data  at  a  relatively  slow  rate. 


91 


Assumptions  are  frequently  made  about  the  human  ability  to  process  visual  information 
based  on  the  achievable  visual  resolution,  the  visual  area  available  to  the  edge  and  the  rate 
at  which  data  itemr  are  absorbed.  This  results  in  quotations  for  information  transfer  at 
very  high  rates.  The  reality  is  that  the  human  visual  system  is  a  highly  selective 
processor.  For  information  about  whicn  there  has  to  be  a  recognition  decision  then  it 
would  appear  that  the  data  absorption  rate  is  around  12  items  per  second,  Clare  1979. 
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Figure  5  Mapping  of  Functions  to  Goals  for  Ground  Attack 

The  low  rate  of  data  take  up  is  often  hidden  by  the  fact  that  each  individual  has  a  detailed 
representation  of  what  to  look  for  in  any  display.  Thus  in  carrying  out  a  task  he  is  able  to 
attend  to  specific  locations  and  details  of  the  items  needed  for  that  task.  This  is  the  reason 
for  the  need  to  maintain  consistency  in  the  location  and  coding  of  displayed  information. 

The  major  problem  in  presenting  information  in  complex  displays  then  becomes  the  time 
needed  to  learn  where  to  find  the  information  necessary  for  each  task  step.  The  way  we 
can  overcome  this  problem  is  to  simplify  the  displays,  preferably  to  the  point  where  only 
that  information  necessary  for  a  decision  step  is  presented.  This,  however,  creates  the 
dilemma  of  how  do  we  define  that  information. 


4  Tools  for  Requirements  Analysis 


There  are  a  number  of  tools  which  have  been  developed  to  mode!  and  specify  data  flow  as 
aids  to  software  design.  Since  we  are  concerned  with  the  data  flow  between  the  human 
and  machine  components  it  is  logical  that  such  tools  could  be  of  use.  There  are  a  number 
of  studies  investigating  such  an  approach  of  which  the  application  of  Job  Process  Charts 
(JPC)  (Tainsh  1985)  and  their  integ-ation  with  CORE  (Mobbs  1985)  has  provided  a  good 
example.  However,  these  approaches  have  been  limited  because  they  have  dealt  primarily 
with  information  flow.  Because  a  critical  aspect  of  the  human  processor  is  the  rate  at 
which  information  can  be  assimilated  and  the  way  in  which  the  information  is  structured, 
it  is  necessary  that  any  requirements  expression  must  take  into  account  the  time  period 


within  which  processes  must  take  place  and  the  data  structures  that  need  to  be  imposed. 

The  Yourdon  methodology,  like  CORE,  addresses  data  flow,  but  it  also  addresses  the 
structure  of  data.  This  allows  the  designer  to  focus  on  the  critical  component  of  the 
information  flows  from  the  system  to  the  pilot  -  that  is  the  key  information  that  he  must 
absorb  in  the  limited  time  available.  Recent  extensions  to  the  Yourdon  methodology  by 
Hatley  and  Pirbhai  (1987)  address  real  time  interactions  and  control  flow;  and  this  allows 
temporal  constraints  and  interactions  to  be  identified  and  modelled,  thereby  refining  the 
basic  data  structure  established  above. 

If  we  consider  the  functional  model,  as  put  forward  for  the  Pilot’s  Associate  then  using  the 
Hatley-Pirbhai  notation  we  get  a  decomposition  as  shown  in  Figure  6.  This  decomposition 
has  omitted  the  Exec  Manager  for  clarity  as  it  interacts  with  all  the  core  functions  by 
providing  supervision  and  control.  What  can  be  seen  is  that  the  resulting  data  flows  are 
complex  and  the  pilot  seems  a  distant  entity  from  the  core  functions.  In  contrast  the 
functional  decomposition  based  on  the  control  model  shown  in  Figure  4  appears  simpler. 


Figure  6  Data  Flow  Decomposition  of  Pilot’s  Associate  Functions 

However,  neither  of  the  representations  at  this  level  deals  with  displayed  information.  The 
problem  is  that  they  show  the  overall  structure  and  not  the  functional  structure  necessary 
for  a  coping  with  a  current  set  of  incompatible  goals.  If  we  return  to  the  earlier  goal 
decomposition  for  the  ground  attack  example,  then  we  define  a  set  of  functions  each 
concerned  with  the  three  top  level  goals.  The  pilot  needs  to  interact  with  each  of  these 
functions  as  is  shown  in  Figure  7.  This  example  is  taken  from  a  decomposition  of  the 
assessment  function  where  a  control  model  has  been  used  to  devise  the  functionality.  In 
this  view  we  can  see  that  the  pilot  is  concerned  with  three  separate  sources  of  information. 
In  most  cases  this  would  be  achieved  by  using  a  visual  display  for  the  Attack  Picture  and 
auditory  displays  to  gain  attention  for  priority  interrupts  for  the  other  two  displays.  In 
current  designs  since  there  is  little  scope  for  prioritising  interrupts  the  only  option  is  to 
switch  a  particular  alarm  off,  as  is  often  done  with  the  radar  warning  system. 
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Figure  7  Data  and  Control  Flow  for  Displays 

If  we  consider  how  we  could  manage  this  interaction  more  effectively  then  we  can 
introduce  the  Exec  Manager  to  control  the  displayed  information,  this  is  shown  in  Figure 
8.  What  also  becomes  apparent  is  that  if  the  pilot  is  to  be  ultimately  responsible  then 
there  must  be  direct  interaction  between  him  and  the  Exec  Manager.  This  has  been  shown 
as  a  control  dialogue  rather  than  a  data  exchange.  It  is  this  dialogue  which  will  need  to  be 
of  the  most  intimate  nature. 


Figure  8  Data  and  Control  Flows  for  Displays  with  Exec  Manager 
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The  goal  decomposition  will  need  to  be  done  to  a  level  which  matches  functions  which 
have  to  be  performed  within  the  time  period  a  pilot  would  dwell  on  a  task  element.  At 
that  level,  the  time  and  data  needs  can  be  defined  and  a  specification  given  to  the  interface 
designer  of  information  X  to  be  assimilated  in  time  T.  Clearly  the  whole  of  the  mission 
profile  is  not  analysed  in  this  depth.  It  will  only  be  necessary  to  carry  out  such  an 
exercise  when  there  are  multiple  tasks  to  be  completed  under  time  pressure. 

A  major  benefit  of  this  approach  is  that  it  is  possible  to  define  time  and  information 
requirements  for  single  screens  or  screen  sequences  from  the  analysis  that  has  been  carried 
out.  These  requirements  can  then  be  used  to  define  performance  criteria  which  can  be 
used  to  test  design  solutions  before  the  full  integration  of  the  whole  system.  Thus  it  will 
be  possible  to  test  critical  displays  early  in  the  design  process  against  objective  measures 
of  performance. 


5  Conclusion 

The  successful  integration  of  intelligent  cooperative  systems  into  the  cockpit  depends  on 
our  being  able  to  provide  for  effective  interaction  between  the  pilot  and  the  other  aircraft 
systems.  To  achieve  this  it  will  be  necessary  to  have  a  good  definition  of  the  data  which 
must  be  exchanged  between  the  pilot  and  the  other  systems.  In  this  paper  a  methodology 
is  proposed  where  by  a  detailed  requirement  of  the  data  with  its  associated  control  is 
developed  by  the  following  steps. 

a)  Detailed  decomposition  of  the  system  goals  carried  out  to  task  units  which  the 
pilot  would  complete  as  a  single  entity. 

b)  Development  of  a  set  of  functions  of  the  total  system  required  to  achieve  those 
task  units. 

c)  Mapping  of  processes  to  those  functions,  where  the  pilot  is  a  processing 
resource,  and  developing  the  associated  control  and  data  flow  model. 

d)  Using  that  control  and  data  model  as  a  specification  for  the  interface  designer  to 
design  and  test  display  options. 

Therefore  the  major  benefit  of  this  approach  is  the  possibility  to  test  design  solutions 
before  the  full  integration  of  the  whole  system.  Thus  it  will  be  possible  to  test  critical 
displays  early  in  the  design  process  against  objective  measures  of  performance. 
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SUMMARY 


Fielding  an  operational  Pilot’s  Associate  (PA)  will  require  both  implicit  and  explicit  representations  of  knowl¬ 
edge.  Speed  and  memory  performance  requirements  for  PA  will  be  aided  by  the  use  of  implicit  representations 
of  knowledge.  Acquiring  and  maintaining  the  large  knowledge  bases  for  PA  will,  by  contrast,  be  aided  by 
having  explicit  knowledge  representations.  The  PA  teams  have  until  now  been  mainly  concerned  with  im¬ 
plicit  representations  because  they  have  been  focused  on  real-time  performance  in  a  limited  set  of  scenarios. 
Explicit  representations  will  become  more  important  as  they  scale  the  system  up  to  include  more  scenarios. 
We  describe  how  machine  learning  techniques  can  automatically  transform  the  explicit  representations  into 
the  implicit  representations.  We  discuss  the  advantages  of  this  approach  for  system  maintenance  as  well  as 
implications  for  pilot  training. 

1.  EXPERT  PERFORMANCE  REQUIRES  IMPLICIT  KNOWLEDGE  REPRESENTATIONS 

The  US  Air  Force’s  PA  program  is  developing  artificial  intelligence  software  for  an  electronic  co-pilot.  Future 
aircraft  will  have  tremendous  sensor,  control,  and  information  resources.  These  resources  will  be  potentially 
of  great  assistance,  but  they  will  also  be  capable  of  easily  overloading  the  pilot  if  they  are  not  made  available 
to  him  in  an  intelligent  way.  The  goal  of  PA  is  to  monitor  the  status  of  the  pilot’s  mission  and  understand 
the  situation  and  the  pilot's  goals  and  intentions.  This  understanding  will  be  required  to  properly  assist  the 
pilot. 

1.1  Pilot’s  Associate  Requirements 

Monitoring  a  mission  and  understanding  a  pilot’s  intentions  in  real-time  is  an  extremely  challenging  task.  It 
requires  several  kinds  of  expertise,  la  particular,  the  PA  system  includes  five  cooperating  expert  systems.  The 
System  Status  module  monitors  the  internal  state  of  the  aircraft.  The  Situation  Assessment  module  monitors 
the  state  of  the  world  external  to  the  aircraft.  The  Mission  Planner  module  performs  route  planning  for  the 
entire  mission.  The  Tactics  Planner  module  creates  tactical  plans  for  short  term  actions  and  maneuvers.  The 
Pilot  Vehicle  Interface  module  interprets  pilot  actions  and  information  requests  and  transmits  information 
from  the  other  modules  to  the  pilot. 

Each  of  these  modules  require  large  knowledge  bases  to  attain  expert  performance  in  their  task.  Much  of 
this  knowledge  is  shared  between  different  modules,  but  it  may  be  represented  differently  and  reasoned  about 
differently  in  each  module.  Finally,  all  of  the  required  interpretation,  message  passing,  and  decision  making 
must  take  place  in  real-time  and  with  a  high  degree  of  reliability  and  accuracy. 

1.2  Need  for  Implicit  Knowledge  Representations 

The  principal  reason  that  PA  must  have  implicit  representations  of  knowledge  is  the  real-time  requirement. 

lThis  work  wss  supported  in  part  by  the  Learning  Systems  Pilot  Aiding  contract  from  the  Wright  Research  and  De¬ 
velopment  Center  (Contract  Number  F33615-88-C-1739).  We  are  pleased  to  acknowledge  the  support  of  our  contract’s 
technical  moniter,  Gurdial  Saini.  We  are  also  indebted  to  the  folowing  members  of  Lockheed's  Pilot’s  Associate  team: 
Mark  Hoffman  and  Gary  Edwards  of  ISX,  David  Smith  of  Lockheed,  Norm  Geddes  of  Applied  Systems  Intelligence, 
and  Belinda  Hoshstrasser  of  Search  Technology.  Jerry  DeJong  of  the  University  of  Illinois  haa  also  been  an  important 
contributor  to  this  effort. 
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One  of  the  key  ways  for  PA  to  achieve  fast  performance  is  to  compile  out  intermediate  reasoning  steps  and 
retain  only  the  final  decisions  or  actions  associated  with  a  given  initial  state.  For  example,  having  a  SAM 
radar  tracking  you  is  generally  a  bad  situation.  One  strategy  to  defeat  the  radar  is  to  become  invisible  by 
reducing  the  aircraft’s  signal-to-noise  ratio.  One  way  to  do  this  if  the  SAM  is  using  doppler  is  to  deny  doppler 
range  data.  This  can  be  done  by  Hying  a  constant  distance  from  the  SAM  site.  One  way  to  do  this  is  to  lly  a 
circular  path  around  the  SAM.  This  requires  that  the  pilot  turns  to  a  certain  heading. 

PA  does  not  need  to  retain  all  of  this  background  knowledge  about  defeating  a  SAM  site,  ft  simply  needs 
to  know  what  actions  should  be  taken  in  the  situation  that  a  SAM  site  is  tracking  it.  Thus,  PA’s  Tactics 
Planner  (TP)  might  have  a  plan  that  ascertains  the  conditions  under  which  it  was  being  tracked  and  then 
simply  recommends  that  the  pilot  turn  to  a  certain  heading.  All  of  the  intermediate  reasoning  about  why  this 
action  is  appropriate  can  be  omitted. 

In  addition  to  omitting  intermediate  reasoning  steps,  there  is  a  second  important  way  of  implicitly  representing 
knowledge  that  contributes  to  efficient  performance  in  PA.  This  is  to  have  specialised  control  structures 
for  the  different  PA  modules.  For  example,  most  tactical  maneuvers  have  explicit  timing  constraints  that 
must  be  satisfied  if  they  are  to  be  successful.  The  TP,  however,  does  not  explicitly  represent  many  of  these 
temporal  constraints.  This  is  because  they  are  implicitly  represented  in  the  TP’s  control  structure  which 
continually  montors  a  situation  over  time  until  a  particular  condition  is  observed.  This  condition’s  occurance 
will  correspond  to  the  temporal  constraint  being  realized. 

For  example,  there  might  be  a  constraint  that  the  pilot  maintains  a  certain  heading  until  the  SAM  site  switches 
from  track  to  search  mode.  The  TP  does  not  have  to  explicitly  represent  this  constraint.  Rather,  its  control 
structure  is  such  that  it  will  repeatedly  sample  the  mode  of  the  SAM  site’s  radar  and  will  report  success  of  the 
maneuver  only  when  the  radar  is  observed  in  search  mode.  The  unit!  relation  is  nowhere  explicitly  represented 
in  the  TP.  It  is  implicit  in  the  control  structure. 

To  summarize,  implicit  representations  of  knowledge  play  an  important  role  in  achieving  real-time  performance 
for  PA.  Two  principal  sources  of  implicit  knowledge  in  PA  are  compiling  out  intermediate  reasoning  steps  and 
having  special  purpose  control  structures. 

2.  KNOWLEDGE  ACQUISITION  IS  FACILITATED  BY  EXPLICIT  KNOWLEDGE  REPRESENTATIONS 

Figure  1  contains  two  rules  that  are  part  of  the  TP's  specialized  representation  for  a  simple  doppler  notch 
plan.  One  rule,  in  effect,  states  that  this  plan  should  be  selected  if  there  is  a  SAM-site  in  track  mode.  The 
other  says  that  if  the  plane  is  not  flying  close  to  a  perpendicular  b~ading  from  the  SAM  then  suggest  a  new 
heading  to  the  pilot  that  will  satisfy  the  perpendicular  requirement.  We  conjecture  that  it  is  much  more 
difficult  to  produce  the  tactical  plan  in  this  complex  representation  than  it  is  to  acquire  general  rules  in  a 
simple  representation  such  as  the  rule  in  Figure  2.  The  TP,  however,  could  never  operate  in  real-time  if  it 
represented  and  reasoned  about  rules  such  as  the  one  in  Figure  2.  Thus,  even  though  it  may  be  easier  to 
obtain  simple  rules,  they  are  not  in  themselves  sufficient  for  the  Tactics  Planner. 

We  have  been  using  Explanation  Based  Learning  (1,4)  to  (semi)-automatically  transform  the  simple  rules 
into  the  specialised  representation  required  for  PA  (2, 3, 5, 6).  The  major  steps  in  this  translation  process  are 
depicted  in  Figure  3.  We  use  EBL  to  learn  a  tactical  plan  by  observing  a  single  example  of  a  tactic  flown 
on  a  flight  simulator.  EBL  accomplishes  this  by  using  an  explicit  domain  theory  to  explain  how  the  example 
achieves  a  stated  goal.  For  example,  the  goal  might  be  to  have  a  SAM-site  switch  from  track  mode  to  search 
mode.  The  domain  theory  contains  general  knowledge  about  the  world.  We  have  used  a  set  of  rules  such  as 
the  one  shown  in  Figure  2  to  learn  a  doppler  notch  plan  for  the  PA  TP  by  observing  a  single  example  of  a  pilot 
flying  such  a  maneuver  on  a  flight  simulator.  The  result  of  the  EBL  process  is  the  macro  shown  in  Figure  4. 

The  macro  shown  in  Figure  4  is  essentially  the  explanation  of  how  the  pilot  achieved  the  goal  of  defeating 
the  SAM  with  the  intermediate  reasoning  steps  of  the  explanation  removed.  All  that  remains  are  the  initial 
conditions  and  any  actions  that  were  performed  and  the  conclusion.  This  macro  rule,  however,  is  still  far 
from  the  representation  required  by  the  TP.  Most  of  the  required  information  is  present,  but  it  is  far  from 
the  correct  format.  For  example,  the  TP  uses  different  types  of  information  in  different  ways.  For  example, 
Figure  1  contains  a  selection  rule  and  an  execution  rule.  Selection  rules  check  for  conditions  that  must  be  true 
in  order  for  a  plan  to  be  viable.  That  is,  only  select  a  plan  if  these  conditions  are  satisfied.  Execution  rules 
monitor  conditions  that  can  change  during  the  life  of  the  plan  and  recommends  that  the  pilot  take  actions  to 
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We  have  defined  two  ways  of  categorizing  the  clauses  in  the  EBL  macro  that  allow  us  to  properly  partition 
the  clauses  as  required  by  the  Tactics  Planner.  First,  we  categorize  a  clause  according  to  whether  it  represents 
something  that  a  pilot  can  easily  control.  For  example,  turning  a  sensor  on  or  off  is  easily  controllable,  but 
getting  a  sensor  locked-on  to  a  track  object  or  making  the  sensor  operational  if  it  is  malfunctioning  are  not 
necessarily  easily  controlled  by  the  pilot.  Second,  we  categorize  clauses  acording  to  whether  their  arguments 
are  constants  or  variables.  If  the  arguments  are  variables  we  further  distinguish  whether  they  are  bound  in 
the  goal  of  the  plan. 

Using  these  categorizations  we  can  automatically  sort  the  macro’s  clauses  into  TP  rule  types.  For  example, 
execution  rules  come  from  clauses  that  are  easily-pilot-controllable  and  have  variables  that  are  not  bound  in 
the  post-conditions  of  the  macro.  Since  they  are  not  bound  in  the  post-condition  they  are  updateable  during 
the  execution  of  the  plan.  Selection  rules  come  from  clauses  that  are  not  easily  controllable  and  have  constants 
as  arguments.  The  constant  arguments  act  like  test  conditions.  Since  they  are  not  easily  controllable  the  plan 
should  only  be  selected  if  these  clauses  are  satisfied. 

After  the  macro  clauses  are  partitioned  according  to  different  types  of  rules  there  is  still  a  further  translation 
step  required  to  put  them  in  the  specialized  syntax  of  the  TP’s  rules.  We  are  presently  working  on  this  step, 
and  it  appears  that  most  of  this  process  can  also  be  automated.  In  summary,  our  research  has  shown  that 
most  of  the  specialized  knowledge  required  for  the  PA  TP  can  be  automatically  acquired  using  explanation 
based  learning  and  an  explicit  and  relatively  simple  domain  theory. 

3.  SYSTEM  MAINTENANCE  IS  FACILITATED  BY  EXPLICIT  KNOWLEDGE  REPRESENTATIONS 

An  important  issue  for  our  approach  to  acquiring  knowledge  is  the  size  of  the  required  explicit  domain  theory. 
If  the  required  domain  theory  for  EBL  is  sufficiently  large  then  it  might  be  more  work  to  build  this  domain 
theory  than  it  would  be  to  simply  build  all  of  the  tactical  plans  directly,  even  if  the  explicit  domain  theory 
rules  are  each  individually  easier  to  build.  We  believe,  however,  that  this  will  not  be  case.  Our  argument 
to  support  this  belief  is  that  the  EBL  domain  theory  is  essentially  a  model  of  the  primitive  functionality  of 
the  aircraft  and  its  environment.  Tactical  plans,  in  contrast,  model  all  possible  behaviours  arising  from  the 
functionality  of  the  aircraft  and  its  environment.  This  is  analogous  to  a  set  of  axioms  and  the  set  of  all  possible 
theorems  that  can  be  derived  from  the  axioms.  The  former  is  typically  a  finite  set  and  the  latter  is  typically 
infinite. 

Thus,  this  argument  implies  that  it  will  not  only  be  easier  to  create  an  initial  PA  system  using  our  approach, 
but  once  the  system  has  been  developed  it  will  be  much  easier  to  modify  and  adapt  the  system.  This  is  because 
the  same  underlying  explicit  domain  theory  should  be  able  to  be  re-coinpiled  in  different  ways  to  create  the 
new  plans. 

At  least  as  important  for  system  maintenance  is  the  fact  that  (semi)-automatically  generated  plans  should  have 
several  advantages  over  hand-generated  plans.  Automatically  generated  plans  should  be  more  consistent.  For 
example,  it  is  well  accepted  among  TP  knowledge  engineers  that  there  is  significant  variability  in  how  different 
knowledge  engineers  will  develop  the  same  plan,  and  even  how  the  same  knowledge  engineer  will  develop  the 
same  plan  if  he/she  were  to  do  it  on  different  days.  We  further  expect  that  automatically  generated  plans 
will  be  more  complete.  For  example,  our  automatically  generated  doppler  notch  plan  included  the  TRACK- 
ID  as  a  parameter  to  send  to  the  PVI.  This  parameter  had  been  inadverdently  omitted  by  a  TP  knowledge 
engineer  who  had  previously  developed  this  plan  by  hand.  This  omission  was  the  cause  of  a  pernicious  and 
long-undetected  bug  in  our  simulator  system.  In  a  similar  sense  we  expect  the  automatically  generated  plans 
shoud  be  more  accurate  and  also  better  justified  and  better  documented  than  hand-generated  plans. 

4  IMPLICATIONS  FOR  PILOT  TRAINING 

An  important  issue  that  has  not  yet  received  much  attention  is  that  pilots  will  both  want  and  need  to 
have  a  thorough  familiarity  and  understanding  of  the  system’s  behaviors,  capabilities,  and  limitations.  It  is 
precisely  this  sort  of  information  that  is  typically  only  implicit  in  the  knowledge  representations  needed  by 
the  performance  requirements  of  PA.  In  order  to  present  this  information  to  a  pilot,  it  will  have  to  somewhere 
be  represented  explicitly.  Thus,  the  representations  needed  for  acquiring  PA  knowledge  bases  should  also  be 
valuable  for  training  pilots  in  the  use  of  PA. 
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Training  pilots  to  use  PA  is  one  aspect  of  pilot  training.  This  aspect  will  be  valuable  to  even  experienced 
pilots  if  they  have  not  yet  used  a  PA  system.  The  explicit  representations  needed  for  acquiring  knowledge 
should  also  be  useful  for  another  apsect  of  pilot  training,  training  inexperienced  pilots.  For  example,  the  PA 
performance  system  might  be  limited  to  advising  a  novice  pilot  to  turn  to  a  particular  heading  in  a  situation 
where  a  SAM-site  is  tracking  him.  In  contrast,  by  using  the  intermediate  knowledge  explicitly  represented 
for  our  learning  system,  a  training  system  could  also  explain  why  the  PA  is  giving  this  advice  and  why  PA 
expects  it  to  be  successful. 

6.  CONCLUSION 

We  are  quite  optimistic  that  over  the  next  year  we  will  successfully  demonstrate  that  our  EBL  approach  can  be 
successfully  employed  to  learn  simple  plans  for  the  PA  Tactical  Planner.  There  remains,  however,  the  question 
about  how  successfully  this  approach  will  scale  up.  At  present  we  only  have  conjectures  that  the  combinatorics 
of  developing  the  domain  theory  needed  for  EBL  will  be  more  favorable  than  the  combinatorics  of  directly 
develoing  tactical  plans.  In  addition  to  the  scaling-up  question  there  are  several  other  important  research 
areas  that  require  attention  with  respect  to  our  EBL  approach,  e.g.,  temporal  reasoning,  geometric  reasoning, 
reasoning  with  uncertainty,  reasoning  about  psychological  models  of  wingmen  and  enemies,  reasoning  with 
imperfect  domain  theories. 

Although  this  list  may  appear  daunting,  we  are  encouraged  by  our  progress  to  date.  One  reason  for  optimism 
is  that  we  have  made  significant  progress  on  at  least  one  of  these  issues  even  though  we  had  not  originally 
planned  to  address  it  for  this  effort.  This  was  the  problem  of  temporal  reasoning.  We  had  originally  hoped 
that  we  could  choose  scenarios  that  would  not  require  explicit  temporal  reasoning,  but  we  found  that  this  was 
not  feasible.  This  was  a  significant  technical  challenge  for  us,  but  we  were  able  to  develop  a  limited  solution 
to  the  problem  that  appears  to  work  well  for  this  domain  (5).  Finally,  we  expect  that  our  approach  will  be 
useful  to  PA  even  before  all  of  these  issues  are  resolved.  For  example,  some  of  our  results  are  already  being 
incorporated  by  the  PA  team  into  their  plans  for  the  next  phase  of  PA,  e.g.,  the  principles  we  presented  above 
for  automatically  identifying  types  of  TP  rules.  We  expect  this  trend  to  grow  stronger  as  our  work  progresses. 
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(DEFRULE  S I MPLE-DOPPLER-NOTCH -MANEUVER- SELECTION 
TEMPS  SAM-SITE  RADAR  NOA 

IF  (SETQ  SAM-SITE  (CAD AAR  (ASSERTIONS  '(DEGRADE  +)  :WHO  PARENTS))) 
(SETQ  RADAR  (PROP  '  RADAR -MODE  SAM-SITE)) 

(EQ  'TRACK  RADAR) 

THEN  (ASSERT  '(INVOCATION-REQUEST)) 

(ASSERT  ' (SAM-SITE-DATA  , SAM-SITE)) 

GOAL  ( (SELECT-DOPPLER-NOTCH-MANEUVER) ) ) 


cjtAre 


(DEFRULE  SIMPLE-DOPPLER-NOTCH-MANEUVER-UPDATE-HEADING 
TEMPS  NOA  HEADING 

LOCAL  SAM-SITE  (CAD AAR  (ASSERTIONS  ' (SAM-SITE-DATA  +) ) ) 

IF  (SETQ  NOA  (ABS  (NOSE-OFF-ANGLE  ‘LEAD-PLANE*  SAM-SITE))) 

(OR  (>  NOA  (+  90  * PERPEND I CULAR- HEAD I NG- DEVI AT ION * ) ) 

(<  NOA  (-  <30  ‘PERPDNDICULAR-HEADING-DEVIATION* )  )  ) 

THEN  (REMOVE-ASSERT  '(PARAMETER  +) ) 

(SETQ  hEADING  (PERPENDICULAR-HEADING  ‘LEAD-PI ANE*  SAM-SITE)) 
(ASSERT  '(PARAMETER  HEADING  , HEADING)) 

(SUGGEST) 

GOAL  ( v UP DATE -DOPPLER- NOTCH -MANEUVER) ) ) 


u.re 


2 


(c-rule 

: name  ' new-maintain-constant-distance 

:type  :non-max 
.■pattern 
'  (<- 

(maintain-constant-distance 
(agentl  ownship) 

(agent2  ?sam-name) 

(interval  ?cnst-dist-interval) ) 

(and 

(relative-ownship-position 
(heading  ?heading) 

(interval  ?int-x)) 

(relative-track-position 
(track-id  ?sam-name) 

(bearing  ’bearing) 

(interval  ?int-y)) 

*f (intersect  ?int-x  ?int-y  ?cnst-dist-intervai; 
#f (nose-off -angle  ?heading  ?bearing  ?noa) 
#f(abs-value  ?noa  ?abs-noa) 

♦p (abs-diff-lt  ?abs-noa  90  7.5)))) 


(  simulator  message  A 
^traffic  ^  r 


EBL 


( General  domain  theoiyy*" 


Uc^acro  >^Trrr]-»(TP^i?r) 


Fi 


lure 


3 


Doppler  Notch  Macro* 


if  (track-class  (track-'d  ?td)  (object-type  l )) 
(track-status  (track-td  ?ld)  (radar-node  track)) 
(relattve-track-posltton  (track-id  ?ld)  (azimuth  ?noa)) 
(fctn  (abs-value  7noa  7abs-noa)) 

(pred  (abs-dtfferehce-less-than  7abs-noa  90  7  5)) 

1  Then  (safe-from-sam  (target  ownship)  (sam-sito  7id)) 


"  tempcral  conditions  are  not  displayed 
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MODELLING  THE  DYNAMICS  OF  PILOT  INTERACTION  WITH  AN  ELECTRONIC  CREW 


Victor  Riley 
Honeywell,  Inc. 

Systems  and  Research  Center 
Minneapolis,  MN 

SUMMARY 

An  approach  to  modeling  complex  interrelationships  between  cognitive  and  situational  variables 
in  pilot  interaction  with  an  electronic  crew  is  described.  The  approach  uses  system  dynamics  to 
express  and  explore  the  interrelationships  between  such  factors  as  how  reliable  the  electronic 
crew  is  during  mission  performance,  the  pilot's  estimate  of  how  reliable  the  electronic  crew  is 
(how  much  the  pilot  trusts  the  electronic  crew),  pilot  workload,  pilot  self  confidence,  task 
difficulty,  and  the  amount  of  risk  associated  with  decisions.  A  small  mathematical  simulation  of 
these  interactions  has  been  developed  to  demonstrate  how  the  model  may  be  used  to  predict  the 
overall  performance  of  the  human-machine  system  and  the  outcomes  of  individual  decisions  in  a 
dynamic  environment. 

1.  INTRODUCTION 

Technology  advances  are  enabling  more  pilot  tasks  to  be  automated,  including  cognitive  tasks  such 
as  situation  awareness  and  decision  making.  While  there  is  a  huge  amount  of  literature  on  the 
psychology  of  interactions  between  people,  there  is  very  little  data  on  the  psychological  issues  of 
human  interaction  with  automation.  For  example,  the  factors  that  influence  pilot  decisions  to  use 
or  not  use  automation  in  a  given  situation  are  unknown,  even  though  such  decisions  are  critical  to 
success  and  survival.  To  make  intelligent  decisions  about  how  automation  should  behave,  how  it 
should  be  applied,  how  much  authority  it  should  have,  and  what  the  interface  to  the  pilot  should 
be,  not  only  must  these  factors  be  identified,  their  behaviors  must  be  understood. 

Because  the  Electronic  Crewmember  (EC)  is  much  more  than  automation,  the  importance  of  these 
psychological  issues  is  enhanced.  An  EC  capable  of  performing  the  pilot's  cognitive  tasks, 
inferring  pilot  intent,  and  dynamically  reallocating  tasks  raises  critical  questions,  such  as:  When 
should  an  EC  take  over  pilot  tasks  or  responsibilities?  What  happens  if  the  EC  incorrectly  infers 
pilot  intent  or  interprets  the  situation?  How  can  responsibilities  be  gracefully  transferred 
between  the  pilot  and  an  EC?  How  can  an  EC  be  made  "pilot-centered”? 

Some  of  the  issues  implicit  in  these  questions  involve  the  psychological  factors  that  contribute  to 
coordination  between  human  teammates.  If  interaction  with  an  EC  is  more  like  interaction  with 
another  human  than  is  usually  the  case  with  automation,  the  general  conclusions  that  have  arisen 
out  of  investigations  in  human  psychology  may  provide  clues  to  how  pilot  interaction  with  an  EC 
will  behave. 

To  identify  potential  factors,  consider  pilot  decisions  to  rely  on  or  override  an  EC  in  a  particular 
situation.  We  may  suggest  that  the  pilot  will  choose  to  override  the  EC  if  he  doesn’t  trust  it  to 
perform  correctly.  He  may  choose  to  rely  on  the  EC  more  or  less  under  conditions  of  high  risk, 
and  whether  he  relies  on  it  more  or  less  may  depend  not  only  on  how  much  he  trusts  it  but  on  his 
level  of  confidence  that  he  can  accomplish  the  task  himself.  In  fact,  we  may  suggest  that  if  his 

level  of  self-confidence  is  higher  than  his  level  of  trust  in  the  EC,  he  will  choose  to  take  control 

himself  in  risky  situations.  He  may  tend  to  rely  on  the  EC  more  under  high  workload  demands. 

In  the  real  world,  of  course,  all  of  these  considerations  and  others  will  act  in  combination.  Any 
given  decision  to  rely  on  or  override  an  EC  may,  in  fact,  be  a  function  of  complex,  dynamic 
interdependencies  between  a  large  number  of  factors.  In  order  to  understand  these  factors,  relate 

them  in  meaningful  ways,  and  model  them  in  a  way  that  is  useful  for  making  design  decisions, 

several  objectives  must  be  accomplished.  First,  factors  of  interest  must  be  defined  in  a  way  that 
is  conducive  to  both  empirical  investigation  and  modelling.  Second,  a  modelling  framework  must 
be  found  that  permits  the  expression  of  complex,  dynamic  interdependencies.  Third,  a  research 
program  must  be  designed  that  enables  the  development  and  testing  of  hypotheses  in  a  particular 
human-machine  system. 
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As  a  first  step  in  this  process,  we  have  addressed  the  issues  of  pilot  trust  in  an  EC.  pilot  self- 
confidence,  pilot  assessments  of  risk,  and  pilot  workload  in  a  dynamic  environment.  We  have 
formulated  operational  definitions  of  these  factors  which  express  them  on  normalized  scales,  and 
we  have  hypothesized  some  interdependencies  and  modelled  them  in  the  DYNAMO  simulation 
language.  The  rest  of  this  paper  will  discuss  parameter  definitions,  the  general  structure  of  the 
model,  a  literature  review  to  identify  reasonable  hypotheses  about  model  behavior,  and  the  model 
itself. 

2.  MODEL  STRUCTURE  AND  DEFINITIONS 

An  initial  model  structure  is  shown  in  Figure  1.  The  figure  depicts  conjectured 
interrelationships  between  operator  skill  level,  task  complexity,  workload,  risk,  trust  in  the  EC. 
self  confidence,  and  EC  reliability.  Each  of  these  factors  may  be  represented  by  variables 
expressed  in  terms  of  probabilities  or  percentages  of  a  resource,  permitting  the  depicted 
structure  to  be  expressed  in  a  mathematical  model  with  normalized  scales.  Some  moderator 
variables  are  also  provided.  For  example,  because  humans  are  generally  poor  at  probability 
judgments  and  own  workload  assessments,  variables  are  provided  for  perceptions  of  risk,  machine 
reliability,  and  workload.  The  directions  of  hypothesized  effects  between  parameters  are  shown 
by  the  arrows. 


Figure  1:  Hypothesized  interrelationships  between  psychological  factors  in  ptlot/EC  interaction 

The  following  definitions  are  used  in  the  initial  model:  Accuracy  parameters  are  defined  as 
percent  of  decisions  or  actions  that  are  correct;  Workload  and  Perceived  Workload  as  a  percent  of 
workload  capacity;  operator  trust  in  the  machine  (Perceived  Reliability)  as  the  operator's 
subjective  estimate  of  the  probability  that  the  next  decision  or  action  made  by  the  machine  will 
be  correct;  operator  Self-Confidence  as  his  or  her  subjective  estimate  of  the  probability  that  his 
or  her  own  next  decision  will  be  correct;  Compliance  as  the  probability  that  the  operator  will 
allocate  responsibility  to  the  machine;  Risk  as  the  probability  of  sustaining  damage  and  Perceived 
Risk  as  the  operator's  subjective  estimate  of  that  probability;  Task  Complexity  as  the  probability 
that  an  unskilled  operator  will  reach  a  correct  decision  or  make  a  correct  action  in  a  given 
instance;  and  Skill  as  the  percentage  of  that  skill  required  for  perfect  performance  possessed  by 
the  operator.  By  defining  parameters  in  terms  of  probabilities  and  percent  of  capacity, 

meaningful  relations  can  be  drawn  between  parameters,  and  parameter  values  may  be  set  or 
determined  in  empirical  studies.  However,  the  definitions  are  necessarily  quite  restrictive  and 

limit  the  applicability  of  the  model.  They  also  do  not  cover  the  possible  multidimensionality  of 
some  of  the  parameters.  Nonetheless,  this  level  of  restriction  is  necessary  to  achieve  a  tractable 
model. 

3.  LITERATURE  REVIEW  ON  PSYCHOLOGICAL  ISSUES  IN  PELOT/EC  INTERACTION 

To  generate  reasonable  hypotheses  about  how  these  parameters  might  behave  in  pilot  decisions  to 
rely  on  or  override  an  EC,  a  literature  review  was  performed  on  human  subjective  probability 
estimates,  trust,  self-confidence,  risk,  and  workload,  with  sources  from  experimental  psychology, 
social  psychology,  engineering  psychology,  human  factors,  and  sociology. 
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Studies  of  subjective  probability  have  provided  guidance  for  the  behaviors  of  the  associations 
between  "risk"  and  "perceived  risk",  "machine  accuracy"  and  "perceived  reliability",  and 
"operator  accuracy"  and  "self-confidence".  In  general,  the  pilot  model  should  tend  to  be 
conservative  when  assessing  posterior  probabilities  (1).  but  overconfident  in  making  predictions 
(2).  It  should  be  unduly  influenced  by  small  sample  sizes  (2),  and  relatively  uninfluenced  by 
independence  of  events  (3),  sample  size,  base  rates,  and  regression  toward  the  .nean  (4). 

Estimates  should  approximate  the  distributions  of  the  events  themselves,  even  among  independent 
events  (3),  and  be  influenced  by  representativeness,  anchoring,  and  availability  (4).  For  model 
performance,  these  results  suggest  several  behaviors.  Pilot  risk  estimates  should  be  influenced 
by  existing  perceptions  of  risk;  that  is,  if  conflict  has  occurred  recently,  the  pilot’s  estimate  of 
current  risk  should  be  higher.  When  developing  an  opinion  about  the  trustworthiness  of  the  EC, 
the  pilot  may  be  unduly  influenced  by  early  experience,  making  strong  predictions  with  little 
data  (5).  Conversely,  the  pilot's  opinion  should  be  more  resistant  to  change  after  more  experience 
with  the  EC,  suggesting  a  moderating  effect  of  the  "duration"  parameter.  Estimates  of  "self- 
confidence"  (own  predicted  accuracy)  and  "perceived  reliability"  (predicted  machine  accuracy) 
should  be  unduly  influenced  by  the  immediately  preceding  outcome. 

Trust  has  been  an  understudied  topic  in  psychology,  despite  its  ubiquity  and  importance  in 
human  affairs.  Studies  of  trust  in  human  psychology  have  failed  to  reach  agreement  on  the 
dimensions  of  trust,  but  do  agree  that  it  is  a  multidimensional  construct  with  both  cognitive  and 
emotive  components.  Although  trust  is  influenced  by  individual  differences,  situational 
influences  are  independently  significant  (6).  Trust  that  does  not  develop  under  conditions  of  low 
workload  but  docs  under  conditions  of  high  workload  may  be  sustained  under  a  later  low  workload 
condition  (7).  When  trust  is  violated,  a  method  of  absolution  is  required  or  trust  will  not  be 
regained  (8).  It  is  thought  that  trust  is  more  easily  destroyed  than  rebuilt,  but  this  is  untested 
(5).  Operators  with  greater  skill  levels  should  have  better  calibrated  trust  in  the  machine  (5). 

For  model  performance,  the  following  behaviors  are  suggested.  "Perceived  reliability"  should 
rise  when  it  is  less  than  the  EC's  "accuracy"  and  fall  when  it  is  higher.  It  should  be  less 
sensitive  as  a  simulated  scenario  progresses,  and  should  be  better  calibrated  to  EC  "accuracy" 
with  higher  pilot  skill  levels.  It  should  fall  faster  than  it  rises,  particularly  after  an  EC  failure. 
Nonetheless,  the  pilot  may  rely  on  the  EC  more  when  subjected  to  high  workload  demands  even  if 
his  trust  in  the  EC  is  low.  This  can  be  accomplished  in  the  model  through  the  "self-confidence" 
parameter  and  its  influence  on  "compliance".  High  "workload"  may  lead  to  low  "self-confidence" 
(predicted  own  accuracy);  if  "compliance"  is  determined  by  the  relation  between  "self- 
confidence"  and  "perceived  reliability",  it  may  be  high  even  when  trust  is  relatively  low.  This 
provides  the  method  of  absolution  necessary  for  a  stable  system  (8). 

Risk  studies  have  been  performed  in  many  areas  of  investigation.  Some  general  results  suggest 
that  higher  skill  levels  lead  to  lower  risk  estimates,  but  that  people  are  generally  overconfident 
in  their  assessments  of  own  risk  (9).  Exposure  to  a  risk  tends  tc  increase  subsequent  perceptions 
of  risk  globally  (10).  For  modelling,  the  "perceived  risk"  parameter  should  be  subject  to  the 
foibles  of  subjective  probability  estimates  in  general.  It  should  be  higher  after  recent  exposure 
to  a  risk,  even  if  the  new  risk  is  not  associated  with  the  old  one.  And  it  should  be  better 
calibrated  to  the  "risk"  parameter  with  higher  levels  of  pilot  skill.  However,  the  issue  of  whether 
the  pilot  will  tend  to  allocate  more  or  less  responsibility  to  the  EC  under  high  risk  conditions 
remains  unaddressed  in  the  studies  cited.  For  modelling,  we  assume  that  this  will  be  determined 
through  the  effect  of  "perceived  risk"  on  "self-confidence"  and  its  subsequent  effect  on 
"compliance". 

Most  of  the  work  on  self-confidence  examined  for  this  effort  addressed  the  relation  between  self- 
confidence  and  performance.  In  general,  it  appears  that  there  is  a  positive  relation  between  the 
two.  but  tne  direction  on  causality  is  unclear.  While  many  studies  indicate  that  higher 
confidence  leads  to  better  performance  (11,  12),  it  may  also  be  true  that  better  performance  leads 
to  higher  self-confidence.  For  modelling,  the  most  conservative  position  at  this  time  is  that  a 
two-way,  positive  linear  relation  exists  between  "self-confidence"  and  "operator  accuracy".  We 
also  hypothesize  a  moderating  function  "confcurve"  that  modulates  "operator  accuracy"  to  account 
for  errors  due  to  over-  or  underconfidence,  although  no  support  for  this  was  found  in  the  current 
review. 

The  difficulty  of  defining  and  measuring  workload  makes  its  treatment  in  the  proposed  model  a 
difficult  issue.  However,  analytic  workload  models  abound,  and  it  is  possible  that  an  analytic 
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tool  based  on  the  proposed  model  may  be  linked  to  such  a  tool  to  provide  estimates  of  pilot/EC 
joint  performance  in  the  presence  of  the  stated  psychological  factors  and  analytically  derived 
workload  profile.  The  definition  of  workload  offered  here  suggests  that  a  workload  scale  input  to 
the  model  must  contain  a  maximum  workload  threshold  so  percent  of  capacity  can  be  determined. 
With  regard  to  the  effect  of  workload  on  performance,  many  investigators  have  conjectured  that  an 
inverted  U-shaped  curve  exists,  with  reduced  performance  at  one  end  due  to  underload  and 
consequential  reduced  vigilance,  and  at  the  upper  end  due  to  overload,  and  some  evidence  for  this 
has  been  found  (13).  For  modelling,  it  seems  appropriate  at  this  time  to  treat  this  relation 
conservatively. 

4.  MODEL  DEVELOPMENT 

Many  of  the  behaviors  described  in  the  previous  section  have  been  modelled  in  a  small 
mathematical  model  of  the  interrelationships  shown  in  Figure  1.  We  have  used  the  DYNAMO 
simulation  language  which  allows  the  expression  of  complex,  time-based  interdependencies 
between  multiple  parameters  in  simultaneously  solved  difference  equations.  Parameters  are 
expressed  as  levels  and  rates,  with  delays,  random  noise,  clipping  functions,  and  other  modelling 
features  available. 

As  an  example,  consider  a  case  where  a  reliable  EC  proves  itself  to  a  skeptical  pilot  until  it  fails 
for  a  short  period.  We  assume  that  risk  and  workload  are  constant  and  the  pilot  is  highly  skilled. 
We  hypothesize  that  the  rate  of  change  of  trust  is  proportional  to  the  difference  between  EC 
accuracy  and  the  pilot's  previous  level  of  trust,  that  its  absolute  value  is  greater  when  the  rate  is 
negative  than  when  positive,  and  that  it  is  less  sensitive  with  greater  duration.  Our  equation  for 
trust  is:  trust. k  =  trust.j  +  dt  (trust.jk);  and  for  trust's  rate  of  change:  rtrust.kl  =  delay  (((maec.k 

-  trust. k)  /  20  clip  (1.7,  .3,  macc.k,  trust. k))  X  (i  -  duration. k)).  Compliance. k  =  sqrt  ((1  - 

confidence. k)  X  trust. k).  System  accuracy  is:  sysacc.k  =  oacc.k  +  compliance  X  (macc.k  -  oacc.k). 

Macc  is  machine  accuracy,  and  some  of  the  numeric  constants  are  arbitrary,  as  are  the  time  units. 

These  equations  produce  the  behavior  shown  in  Figure  2  (14). 


Figure  2:  Sample  output  from  DYNAMO  model  (hand-drawn  replication) 

Many  complex  behaviors  can  be  observed  by  providing  various  profiles  of  machine  accuracy,  pilot 
workload,  and  risk,  and  different  behaviors  can  be  observed  with  different  skill  levels.  However, 
not  all  of  the  hypotheses  identified  in  Section  3  have  been  modelled  yet,  and  empirical  validation 
in  a  human-machine  context  remains  to  be  done. 

5.  CONCLUSION 

The  model  and  literature  clues  presented  offer  a  framework  and  initial  hypotheses  for  addressing 
complex  and  dynamic  interdependencies  between  cognitive  and  situational  variables  in  pilot 
interaction  with  an  Electronic  Crew. 
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Abstract 

The  concept  of  human-electronic  co-operation  in  the  cockpit  is  synonymous  with 
that  of  a  team.  Whether  or  not  team  members  interact  effectively  will  rely  largely 
upon  the  pilot's  acceptance  of  his  electronic  team  mate.  This  paper  reports  on  the 
attitudes  of  eight  British  Aerospace  test  pilots  towards  the  future  of  such  co¬ 
operation.  Particular  emphasis  is  laid  upon  the  factors  of  system  function,  task 
allocation  and  trust.  Pilots  opinions  are  examined  against  a  schema  of  'Operational 
Relationships',  recently  proposed  in  the  literature  . 

I  INTRODUCTION 

The  purpose  of  this  paper  is  to  address  the  issues  of  trust  and  acceptance  in  cockpit 
human/electronic  teamwork.  There  is  a  legitimate  concern  that  the  strategy  of 
automating  all  of  the  pilot  tasks  which  it  is  technically  feasible  to  automate  is 

unlikely  to  provide  the  optimum  design  for  the  future  human-electronic  aircrew 
team  (eg.  Hollister  1986).  A  first  defence  against  this  can  be  achieved  by 
developing  a  close  liaison  between  the  system  designer  and  the  pilot  population. 
This  should  help  in  the  identification  of  those  tasks  whose  automation  would,  in 
the  opinion  of  aircrew,  be  most  beneficial  and  thus  enhance  the  likelihood  of  pilot 
acceptance. 

British  Aerospace  (Military  Aircraft)  Limited  employ  a  number  of  pilots  to 
perform  test  flying  on  aircraft  such  as  the  Harrier,  Hawk  and  Tornado  Aircraft. 
These  pilots  have  many  years  of  fast  jet  experience  in  the  Royal  Air  Force  or  Royal 
Navy,  Fleet  Air  Ann  as  well  as  in  other  NATO  forces.  This  pool  of  experience  offers 
BAe  an  opportunity  to  gather  opinions  and  gauge  initial  reactions  to  the  specific 

and  general  acceptability  of  automation. 

Questionnaires  and  structured  interviews  were  used  to  elicit  the  views  of  eight  BAe 
test  pilots  regarding  the  functions  and  philosophies  that  should  drive  the 

integration  of  automated,  semi-automated  and  human-electronic  co-operative 
technologies  in  the  cockpit.  The  pilots  had  a  total  of  31400  hours  of  fast  jet  flying 
experience  (Details  are  given  in  Section  1.1).  During  these  interviews  reference 
was  made  to  the  concept  of  Operational  Relationships  (OR)  as  described  by 
Krobusek,  Boys  and  Palko  (1988).  In  this  schema  ten  distinct  categories  of 
Operational  Relationship  are  defined.  These  range  from  OR'A',  where  the  pilot 
performs  the  activity,  to  OR'G'3,  where  the  system  may  perform  the  action 

autonomously.  All  10  are  listed  below  in  Table  1,  and  were  used  after  the  interviews 
to  categorise  responses.  During  the  interviews  the  concepts  were  used  to  prompt 
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the  pilots  to  consider  the  possibilities  and  potential  for  cockpit  automation. 
Throughout  this  paper  opinions  are  related  to  this  schema. 

Table  1  'Operational  Relationship'  Summary  Table 


OR* A'  -  The  pilot  performs  the  activity 

OR'B'  -  The  (relatively  straightforward)  activity  is 

performed  automatically  by  the  system. 

OR'C*  -  The  system  may  remind  the  pilot  if  the  pilot 
asks  or  has  authorised  such. 

OR'D’  -  The  system  may  remind  the  pilot. 

OR'E'  -  The  system  may  prompt  the  pilot  (with 
unrequested  information). 

OR'F’  -  The  system  has  been  given  authority  to 
perform  function,  but  with  pilot  consent. 

OR'G'  -  The  system  may  perform  an  action  only  if 
various  conditions  are  met. 

OR'G’l  -  The  system  may  perform  the  action,  but 
must  concurrently  notify  the  pilot. 

OR'G' 2  -  The  system  may  perform  the  action,  but 
must  notify  the  pilot  when  first  convenient  for  the 
pilot. 

OR'G'3  -  The  system  may  autonomously  perform  the 
action. 

The  interview  techniques  required  pilots  to  iteratively  address  specific  elements 
and  aspects  of  the  piloting  task,  the  aircraft's  systems  and  it's  operational  role.  This 
provided  a  flexible  structure  within  which  pilots  could  consider  existing 
automation  requirements  as  well  as  future  possibilities.  Four  general  areas  were 
addressed,  these  were  (i)  the  management  of  the  aircraft  systems,  (ii)  situation 
assessment,  (iii)  tactics  and  (iv)  the  man  machine  interface. 

1.1  PILOT  EXPERIENCE 

Details  of  the  fast  jet  flying  experience  of  the  eight  pilots  interviewed  are  given  in 
Table  2  below. 


Table  2  Approximate  Pilot  Logs 


Hours 


Pilots  Aircraft  include: 

PI  2  3  4  5  6  7  8  Tornado(IDS/ADV) 

Jaguar 

4700  3500  3000  3500  4000  3500  4200  5000  Hunter 

Jet  Provost 

Hawk 

EAP 

Total  31400  hours  Harrier  (+Sca) 

F16 

Phantom 
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2  MANAGEMENT  OF  AIRCRAFT  SYSTEMS 


2.1  Engines 

In  general  the  pilots  welcomed  engine  automation,  although  they  could  not  easily 
envisage  the  potential  for  automation  beyond  the  fully  digital  engine  controls 
current  in  GR5  Harrier  or  proposed  for  EFA.  Nonetheless,  further  automation 
would  be  welcomed  if  it  maximised  opportunities  for  the  pilot  to  assimilate  higher 
level  information  by  reducing  engine  system  distractors.  Particular  emphasis  was 
laid  upon  the  desirability  of  the  system  performing  all  pre-flight  checks  and  start¬ 
up  procedures  as  there  is  considerable  pressure  upon  the  pilot  at  this  stage  in  a 
mission,  especially  if  'scrambled'.  At  this  stage  in  a  mission  pilots  wished  to  only  be 
alerted  only  if  a  significant1  system  failure  was  detected  (OR'G'l)  believing  that 
self-correcting  systems  should  self-correct  autonomously  {OR'B*}.  Following  a 
system  failure  it  was  suggested  that  details  relating  to  the  performance  penalty  of 
that  failure  would  be  required  as  the  pilot  may  decide  to  fly  in  spite  of  the  failure. 
Thus  pilots  welcomed  decision  aiding  but  did  not  wish  the  system  to  take  a  FLY/NO¬ 
FLY  decision. 

In  general  pilots  believed  that  the  aim  of  engine  automation  should  be  to  provide 
'care-free'  handling  particularly  during  periods  of  high  mental  workload  as 
experienced  in  low  level  flight  and  during  emergencies  or  combat  situations.  This 
could  only  be  achieved  if  the  system  was  of  a  sufficiently  high  integrity  to 
engender  a  high  level  of  trust. 

2.2  Fuel  and  Hydraulic  Systems 

Current  fuel  system  automation  is  considered  to  be  at  a  fairly  high  level,  although 
past  experience  has  shown  the  importance  of  a  'transparent'  system  that  enables 
the  pilot  to  confidently  assume  control  of  the  system  in  the  event  of  a  failure.  Pilot 
opinion  was  entirely  in  favour  of  further  hydraulic  automation,  although  there 
was  disagreement  concerning  the  OR  that  should  govern  these  procedures 
(ranging  over  OR'F';OR'G&  OR'G'l).  Pilots  stated  that  they  would  wish  to  sanction 
(OR'F')  any  automated  procedure  that  would  affect  aircraft  performance  (eg. 
moving  fuel  may  affect  centre  of  gravity).  It  was  suggested  that  pilots  should  not 

have  to  bother  themselves  with  fuel  or  hydraulic  system  operations,  although 
high  level  information  was  essential  (eg.  range,  kg.  left,  undercarriage  status) 

It  was  recognised  that  the  requirement  for  information  and  sanctioning  may  be 
part  of  the  process  of  developing  trust  in  an  automated  system. 

2.3  Battle  Damage,  Faults,  Malfunctions 

In  general,  pilots  did  not  want  to  be  informed  of  the  technical  diagnosis  of  specific 

types  of  battle  damage,  fault  or  general  malfunction.  Rather,  under  these 

conditions  they  wanted  the  system  to  reconfigure  following  OR’G'3  with  the 
qualification  that  should  operational  capabilities  or  flight  performance  be 
affected  the  system  should  immediately  inform  the  pilot  of  these  new  parameters. 
Again  this  is  an  example  of  the  need  for  decision  aiding  requirements  to  parallel 

those  of  automation. 


1  'Significant'  in  this  context  refers  to  factors  that  will  affect  flight 
performance  or  operational  capability 
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2.4  Avionics 


Automation  of  navigation  systems,  which  involve  many  routine  tasks,  was  believed 
to  be  a  sensible  goal  although  cautionary  reference  was  made  to  the  integration  of 

early  automated  Inertial  Navigation  systems  which  were  found  to  increase  rather 
than  reduce  workload  due  to  their  poor  reliability.  Although  opinion  differed  upon 

the  level  of  autonomy  (LOA,  see  also  Krobusek,  Boys  and  Palko  (op  cit.)  at  which 
specific  navigation  and  other  avionic  systems  should  be  set,  there  was  general 
agreement  that  automated  system  functions  should  remain  hidden  until  a  pre¬ 
defined  point  at  which  the  system  would  request  authorisation  to  continue,  thus  in 

effect  proposing  a  variant  of  OR'F'.  The  point  was  reiterated  that  if  a  function  could 
be  automated  with  high  reliability  and  the  effect  of  this  automation  had  no  effect 
upon  the  aircraft's  performance  then  the  fact  of  that  automation  should  remain 
hidden  from  the  pilot.  However  as  recommended  by  Krobusek,  Boys  and  Palko  (o  p 
cit.)  it  was  agreed  that  such  events  be  recorded  for  later,  in-flight  perusal.  This 
appears  to  support  a  special  case  of  OR  'B',  but  with  the  qualification  that  such 
events  be  recorded  in  case  they  impact  upon  other  factors  later  in  a  mission. 

3  SITUATION  ASSESSMENT 

3,1  Automated  Sensor  Management 

All  pilots  agreed  that  an  automated  sensor  manager  that  presented  an  accurate 
tactical  'picture'  was  required,  but  were  sceptical  about  how  accurate  such  a 

system  could  be  due  to  the  number  of  variables  that  must  be  considered  and  the 

often  stated  requirement  to  retain  flexibility.  Although  such  flexibility  may  be 

achieved  by  pre-setting  the  'goals'  of  a  sensor  manager's  LOA  (eg.  be  stealthy  until 

x  etc)  pilots  were  in  general  unwilling  to  accept  the  concept  of  L’sOA  at  a  more 

complex  level  than  that  of  sophisticated  tactical  decision  aider  or  mission 
management  aid.  Overall  the  concept  of  L'sOA  as  interpreted  by  pilots  at  the 

highest  level  of  authority  did  not  extend  to  that  of  dynamic  re-allocation  of 

function.  The  highest  acceptable  level  was  perceived  to  be  that  of  pre-flight 
presets  of  the  functions  that  would  be  performed  by  the  pilot  and  by  the  system. 
The  consensus  appeared  to  be  that  L'sOA  would  not  (and  should  not)  be 
reconfigurable  in  flight.  This  view  appeared  to  be  driven  by  the  realisation  that 
dynamic  re-allocation  of  function  and  in-flight  LOA  resets  would  occur  during 
high  workload  periods  and  potentially  contribute  to  confusion  during  highly 
inopportune  phases  of  a  mission.  It  seems  likely  that  the  most  useful  arrangement 

of  pilot-system  co-operation  (LOA)  will  be  predictable  because  it  will  be  necessary 
to  reduce  the  ocvurrence  of  variations  in  this  relationship  during  periods  when 
the  pilot  is  integrating  the  tactical  significance  of  many  external  variables. 

Pilots  did  agree  that  a  high  integrity  automated  sensor  suite  would  be  extremely 

useful  and  afford  a  significant  combat  advantage  for  the  pilot.  Recent 

developments  such  as  auto-scan  centering  and  auto-scan  volume,  as  used  in  radar 

target  acquisition,  have  been  enthusiastically  received  due  to  the  accompanying 

large  reductions  in  workload.  Although  pilots  believed  that  automated  sensor 

management  and  sensor  correlation  were  priorities,  they  were  concerned  about 
the  integrity  of  such  a  system.  Pilots  suggested  that  trust  and  confidence  in  such  a 
system  could  only  be  brought  about  through  repeated  trials  in  which  the  auto- 
sensor's  'picture'  was  found  to  be  more  accurate  than  that  which  the  pilot  had 

developed  from  the  usual  sensor  sources.  It  was  suggested  that  it  would  be  essential 
to  attach  confidence  levels  to  the  fused  and  correlated  output  of  such  systems.  Thus 
sensed  information  could  be  presented  in  a  form  such  as  "I'm  70%  sure  this  is  a 

Flanker".  Given  these  integrity  and  probability  pre-conditions,  pilots  believed  that 
they  would  accept  sensor  management,  correlation  and  fusion  at  OR'G‘3. 
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3.2  Automated  Defensive  Systems  (DAS) 

Defensive  aids  systems  automation  was  generally  considered  a  good  idea,  although 
pilots  were  concerned  that  the  system  could  easily  be  spoofed  (tricked  into  making 
an  error  of  commission,  a  false  identification  of  a  threat).  To  cope  with  this 

eventuality  most  pilots  believed  that  an  OR'G'l  level  would  be  required  but  also 
mentioned  that  the  need  to  regularly  monitor  the  system  to  detect  spoofing  might 
increase  workload.  As  with  most  systems  manual  override  was  considered  essential. 

All  pilots  were  unanimously  opposed  to  the  concept  that  the  DAS  should  be  linked 
to  the  flight  control  system  (FCS)  such  that  automated  missile  'Break’  procedures 
could  be  undertaken  without  forewarning.  Although  several  rationales  were 
provided,  (including  those  of  system  error,  spoof/annoyance  factors  and  the 

potential  for  physical  injury)  opposition  to  this  proposal  was  sufficiently  strong  to 

suggest  that  automated  FCS  intervention  'went  against  the  grain'  at  a  fundamental 
level.  Missile  'Break'  related  automation  was  acceptable  only  at  OR'E'(eg.  BREAK 

PORT). 

4  TACTICS 

There  was  little  agreement  concerning  the  usefulness  of  automated  tactics  systems 
(ATS),  but  all  felt  that  tactics  would  be  the  most  complex  pilot  tasks  to  automate  due 
to  the  inherent  dynamic  and  flexible  nature  of  combat.  As  discussed  previously, 
pilots  appeared  reluctant  or  unwilling  to  conceive  of  a  tactical  level  of  human- 
electronic  co-operation  that  exceeded  that  of  sophisticated  decision  aid. 

Interestingly  the  point  was  made  that  a  capability  to  vary  tactical  L'sOA  (on  the 
ground)  may  be  useful  as  a  pilot  training  aid  for  less  experienced  pilots,  although 
it  was  stated  that  the  logic  and  reasoning  employed  by  the  system  must  be  very 

clear.  Pilots  felt  that  the  optimum  role  for  ATS  would  be  the  computation  of  target 
engagement  paths,  missile  release  zones  and  paths  of  egress.  Most  pilots  believed 
that  these  functions  should  operate  at  OR'E'  levels,  although  some  pilots  felt  that 
they  may  wish  to  allow  the  system  to  carry  out  the  engagement  through 

sanctioning  system  control  of  the  FCS  (OR’F).  All  pilots  agreed  that  regardless  of 
the  OR  covering  target  engagement  the  pilot  must  perform  the  weapons  release 
task  himself  (OR'A'}.  One  pilot  could  see  the  full  potential  for  this  type  of 
automation  stating  that  should  the  pilot  delegate  target  engagement  procedures  to 
the  automated  system,  this  would  - 

" . allow  one  aircraft  to  almost  have  the  capability  of  two,  as 

the  pilot  will  be  able  to  cover  against  threats  and  check  systems 

just  as  a  second  crew  member  would  do.” 

There  was  a  general  feeling  amongst  the  pilots  that  although  they  could  imagine 
the  potential  role  of  an  ATS  decision  aid  they  would  have  difficulty  trusting  the 
validity  of  these  displays  or  indeed  the  information  upon  which  they  were  based.  A 
typical  comment  concerned  the  auto-detection  of  a  SAM  site,  it  was  believed  that 
pilot's  would  wonder  (a)  is  it  really  a  SAM  site  ?  (b)  has  the  site  run  out  of  missiles? 
(c)  is  it  just  illuminating  (spoofing)  with  it's  radar  ?  Pilots  felt  on  the  whole  that 
they  would  be  reluctant  to  trust  such  a  system  or  the  data  upon  which  it  made  its 
decisions.  Two  general  accompanying  comments  were  made,  these  were  that  : 

(1)  The  most  useful  tactical  decision  aiding  would  be  the  identification  of 
targets  (Automated  sensor  management)  together  with  details  of  target 
performance  capabilities  together  with  own  optimum  engagement 
parameters  (eg.  intercept  speed  and  course). 

(2)  The  tactical  automation  'nightmare'  is  that  the  automated 


aircraft  provides  lots  of  clear  tactical  information  to  the  pilot,  but  that  this 
information  is  wrong  because  the  system  is  being  spoofed. 

5  MAN  MACHINE  INTERFACE  (MMI) 

All  pilots  agreed  that  the  MMI  of  automated  systems  would  be  critical  to  aircrew 

acceptance  of  such  systems.  A  major  concern  was  that  the  pilot  should  be 
presented  with  ar.  unambiguous  display  of  'who'  was  in  control  of  'what'.  There 

was  also  concern  that  the  pilot's  desire  to  be  told  what  the  system  was  doing 

(OR'G'l)  or  to  sanction  automated  actions  {OR'F}  might  actually  increase  his 

workload. 

It  was  unanimously  agreed  that  there  is  already  too  much  displayed  information 
in  the  cockpit  for  the  pilot  to  reliably  intake  at  periods  of  high  workload  and  that 
the  proliferation  of  sensor  and  weapon  aiming  systems  will  exacerbate  this 
problem,  particularly  in  single  seat  aircraft.  Consequently  an  MMI  priority  is  to 
reduce  the  amount  of  information  presented  in  the  cockpit  by  concentrating  on 

the  fused  and  correlated  'high  level'  information  to  be  presented  to  the  pilot 

(eg. "port  flap  hydraulic  failure"  or  "port  flap  stuck  at  IS  degrees”  is  less  useful 
than  "starboard  roll  reduced  to  **"etc)  .  Thus  the  pilot  should  immediately  be 
aware  only  of  the  fact  and  the  implications  of  significant  changes  within  or 
outside  his  aircraft.  The  significance  of  an  event  will  require  clarification 
through  further  research,  nonetheless  significance  appears  related  to  the  impact 
of  events  upon  operational  performance,  tactics  and  safety. 

Most  pilots  agreed  that  during  periods  of  high  workload  it  would  be  extremely 
advantageous  if  an  automated  system  could  prioritise  information  and  present  this 
at  a  time  when  this  would  not  be  distracting.  This  is  similar  to  a  special  case  of 
OR'G'2  in  which  the  concept  of  'performing  an  action'  is  changed  to  'gathering 
information',  rendering  the  nature  of  the  human-electronic  interaction  closer  to 
that  of  human  co-operation  rather  than  a  simple  shift  of  the  locus  of  executive 

control. 

6  GENERAL  ISSUES 

A  number  of  general  issues  emerged  from  the  interviews  that  have  bearing  upon 
the  integration  of  the  human-electronic  team  and  the  pilots  ability  to  speculate 

upon  such  a  relationship. 

6.1  Operational  Relationships 

The  concept  of  OR's  was  easily  understood  by  all  pilots,  although  the  pilots  varied 
in  the  level  of  the  OR  they  were  prepared  to  allocate  to  human-electronic 
teamwork.  This  in  itself  may  support  the  concept  of  ‘Pilot  Tailoring'  a  process 
which  would  essentially  customise  a  pilot's  individual  LOA  requirements.  It  was 
suggested  that  the  ten  OR's  proposed  by  Krobusek,  Boys  and  Palko  (op  cit.)  could 
in  fact  be  simplified  for  the  purposes  of  gauging  pilot  opinion  to  : 

a)  The  system  does  it  alwa-  ■>  {OR’B','G'3} 

b)  The  system  does  it  soon,  w  {OR  'G'} 

c)  The  system  does  it  and  U.  ;  the  pilot  (either  then  or  later).  {OR  'G'1,’G'2) 

d)  The  system  asks  the  pilot  to  be  allowed  to  do  it.  (OR’F) 

e)  The  pilot  does  it.  {OR  A) 

Those  OR's  omitted  from  the  original  schema  {OR  'C','D','E'}  appear  qualitatively 
different  from  the  rest  and  as  such  may  be  better  suited  to  a  schema  describing 
levels  of  decision  aiding. 
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6.2  Levels  of  Autonomy 


In  general,  pilots  had  some  difficulty  imagining  functional  models  of  LOA 
concepts.  There  existed  a  general  resistance  to  the  concept  that  human-electronic 

team  co-operation  could  be  redefined  whilst  in-flight.  Although  the  concept  of 
'pilot  tailoring*  was  welcomed  it  was  believed  unlikely  that  these  parameters  would 
be  rc-tailored’  between  missions  due  to  the  sheer  complexity  of  remembering 

another  set  of  \ '  riables.  A  point  made  throughout  all  the  interviews  was  that 
reducing  the  complexity  of  aircraft  systems  must  be  the  goal  of  automation.  Pilots 

added  that  they  may  well  not  interact  with  systems  that  added  significant 
complexity  to  their  task  even  if  those  systems  could  buy  an  operational  advantage. 

Although  Krobusek,  Boys  and  Palko  (op  cit.)  argue  that  the  end  product  of 
integrating  an  LOA  approach  within  automated  aircraft  systems  would  buy  a 
"very  dynamic  range  of  performance"  for  the  system,  pilots  appear  more 
concerned  that  they  should  understand  exactly  what  the  performance 
characteristics  of  all  their  aircraft  systems  will  be  throughout  an  entire  mission, 

an  assumption  that  does  not  allow  for  a  wide  range  of  in-flight  variations  to  the 

co-operative  human-electronic  team  relationship.  The  LOA  concept  did  receive 
support  from  some  pilots  who  suggested  that  it  would  provide  a  useful  training  and 
combat  aid  for  the  inexperienced  pilot. 

7  )  CONCLUSION 

Overall,  the  pilots  welcomed  automation  that  would  relieve  them  of  tasks  during 
periods  of  nigh  critical  workload  and  of  carrying  out  mundane  and  routine 
monitoring  tasks.  Whilst  there  is  a  degree  of  mistrust  and  scepticism  concerning 
the  integrity  and  reliability  of  future  automated  systems,  the  development  of  such 

systems  are  enthusiastically  supported  as  they  are  seen  as  the  only  means  by 

which  the  pilot  will  be  able  to  cope  with  the  workload  demands  anticipated  from 

forthcoming  aircraft  systems.  However,  it  appears  that  an  effect  of  this 

underlying  mistrust  is  that  most  of  the  pilots  interviewed  wish  to  be  presented 
with  information  on  at  least  some  aspects  of  the  automated  decision  making 
processes,  a  requirement  which  might  actually  increase  the  workload  associated 

with  a  given  task.  Interestingly,  the  pilots  opinions  were  similar  to  those  in  the 
sample  reported  by  Taylor  (1988)  in  venturing  that  trust  in  automated  systems 

would  not  actually  develop  through  the  presentation  of  premises  and  hypotheses 
upon  which  automated  decisions  had  been  made  but  that  an  individual's  trust 
would  develop  when  the  system  repeatedly  'got  it  more  right’  than  the  pilot. 
Ultimate  acceptance  of  highly  automated  systems  would  be  achieved  only  when 
the  'folklore'  of  trustworthiness  generated  by  reliable  systems  is  passed  onto  the 

next  generation  of  pilots. 

Many  pilots  expressed  a  strong  concern  that  automation  will  be  introduced 

without  fully  taking  into  account  the  tasks  that  the  pilot  performs,  resulting  in  a 
system  that  will  not  be  used  or  liked. 

The  sample  of  pilots  interviewed  in  this  survey  was  relatively  small  and  hence 

their  opinions  should  not  be  considered  representative  of  the  pilot  population  as  a 
whole.  Their  experience  and  backgrounds  may  have  tended  to  encourage  a 

greater  caution  and  apprehension  of  automation  concepts  than  would  be  found 

amongst  those  pilots  who  are  currently  joining  squadrons. 

Finally,  it  should  be  recognised  that  pilot  opinions  are  just  that,  they  may  be 

wrong,  they  undoubtedly  differ  and  and  they  will  probably  change.  However, 

ultimately  pilot  opinion  will  determine  whether  or  not  the  human-electronic 

team  members  really  do  work  together  as  a  team. 
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PSYCHOLOGICAL  PRINCIPLES  FOR  HUMAN-ELECTRONIC  CREW  TEAMWORK 


S.J.  SELCON  AND  R.M.  TAYLOR 
Royal  Air  Fores  Institute  of  Aviation  Medicine, 
Famborough,  Hants. 


1.  INTRODUCTION 

Human-Electronic  Crew  teamwork  is  the  co-ordination  of  activities  of  human  and  machine 
components  of  advanced  crew  systems,  employing  both  conventional  and  artificial  intelligence 
computational  techniques,  where  there  is  an  orientation  towards  common  goals  and  objectives. 
Paradigms  and  metaphors,  such  as  Human-Electronic  Crew  teamwork,  provide  both  guiding  and  limiting 
frameworks  for  structuring  thinking  about  crew  systems  interface  design.  Traditionally,  aircrew 
interface  design  has  been  guided  by  the  manual  control  paradigm,  involving  a  closed-loop  negative 
feedback  control  system,  with  the  human  as  the  adaptive  element.  Improvements  in  flight  technology 
and  aircraft  capability  revealed  limitations  on  manual  control  in  IMC/IFR  conditions,  with  the  potential 
for  loss  of  control  in  highly  dyns  c  environments,  unusual  positions  and  high  G.  The  introduction  of 
automation  technology  gave  curre.  sy  to  the  supervisory  control  paradigm,  with  the  transfer  of  some 
human  functionality  to  automation,  and  with  the  human  operator  allocated  a  system  management  role. 
Experience  has  revealed  the  unreliable  nature  of  human  monitoring  performance,  with  problems  of 
undetected  degradation,  and  reduced  operator  intervention  capability.  Now,  the  prospect  of  utilising 
machine  or  artificial  intelligence  (Ai)  has  encouraged  the  use  of  the  problem-solving  paradigm  for 
interface  design.  This  focuses  design  effort  on  how  the  interface  can  be  created  to  help  perform  the 
mission  (EGGLESTONE,  1988). 

In  1988,  participants  at  the  1st  Joint  GAF/RAF/USAF  Workshop  on  the  Human  Electronic  Crew 
broadly  agreed  that  teamwork  provides  an  appropriate  metaphor  for  characterising  the  relationship 
between  the  human  and  AI  system  components  needed  to  solve  mission  problems  (EMERSON  et  al, 
1988)  In  the  military  aviation  environment,  mission  problems  are  characterised  by  uncertainty  and 
ill-structure.  They  require  flexibility  in  handling  contingencies  as  they  arise,  rather  than  as  planned. 

In  dealing  with  this  requirement,  AI  system  interface  design  needs  to  reduce  operator  workload, 
improve  operator  situational  awareness,  and  enhance  decision-making  performance  by  creating  an 
improved  integration  or  matching  between  the  human  and  electronic  crew  capabilities.  The  difficulties 
that  seem  most  likely  to  arise  are  in  the  areas  of  creating  trust,  maintaining  goals  and  in  achieving 
appropriate  levels  of  autonomy  in  such  a  teamwork  relationship. 

The  aim  of  this  paper  is  to  develop  an  improved  understanding  of  the  requirements  for  teamwork  in 
the  Human-Electronic  Crew  with  reference  to  the  literature  on  social  psychology  and  computer  aiding. 
Through  this  analysis,  it  is  intended  to  identify  key  dimensions  that  characterise  levels  of  maturity  in 
teamwork,  with  particular  regard  to  problem  solving  and  decision  making  under  uncertainty.  We  will 
attempt  to  incorporate  these  dimensions  into  a  prototype  audit  tool  for  evaluating  the  quality  and 
maturity  of  Human-Electronic  Crew  teamwork. 

2.  TEAMWORK  MODEL 

In  order  to  examine  the  requirements  for  Human-Electronic  Crew  teamwork,  we  will  be  guided  by 
a  generic  model  representing  the  system  of  relationships  between  different  aspects  of  teamwork.  The 
model  proposed,  shown  in  Fig.  1 ,  is  derived  from  the  social  psychology  of  small  group  dynamics 
(McGRATH,  1964)  Teams  differ  from  small  groups  in  the  greater  emphasis  placed  in  teams  on  clear 
definition  of  goals,  roles  and  structure.  Teams  have  three  distinctive  characteristics: 

a)  Co-ordination  of  activity,  aimed  at  performing  certain  tasks  and  at  achieving  specific,  agreed 
goals 

b)  Well-defined  organisation  and  structure,  with  members  occupying  specific  roles  with  associated 
power,  authority  and  status,  whilst  exhibiting  conformity  and  commitment  to  team  norms  and 
goals 

c)  Communication  and  interaction  between  team  members,  which  we  refer  to  as  team  processes. 

The  system  of  relationships  between  the  components  of  teamwork  can  be  understood  in  terms  of 
the  team’s  goals,  resources,  structures,  and  processes,  and  their  effects  on  individual  team  members, 
team  development  and  team  performance.  Two  system  feedback  loops  can  be  identified,  namely: 

a)  Feedback  on  performance  of  the  team's  task,  compared  with  team  goals,  possibly  leading  to 
changes  in  team  resources,  e  g.  recruitment  of  additional  expertise. 

b)  Feedback  affecting  team  structure  as  both  individual  members  and  the  team  develop,  (earn  and 
adapl  to  changing  goals  and  task  demands,  e  g.  dynamic  function  allocation,  initiative  turn-taking, 
emergent  leadership 

i  lb 


FIGURE  1  ■  Teamwork  Modal. 

We  propose  to  examine  the  requirements  for  Human-Electronic  Crew  teamwork  in  relation  to  the 
individual  components  of  this  generic  model.  Each  component  will  be  addressed  in  two  parts.  Firstly, 
we  will  summarise  relevant  heuristics  and  guidance  on  teamwork  derived  from  a  selective  review  of 
social  psychology  literature  (PENNINGTON,  1986;  EIMER,  1987a;  WELLENS  AND  McNEESE,  1987; 
LARSON  AND  La  FASTO,  1989).  Secondly  we  will  Identify  some  of  the  principal  issues  raised  for 
Human-Electronic  Crew  teamwork,  based  on  current  applications  of  decision  support  systems,  with 
relevance  to  the  teamwork  model  components. 


3.  TEAM  GOALS 

3.1  TEAM  GOALS  :  SOCIAL  HEURISTICS 

Effective  teamwork  is  strongly  associated  with  a  clear  understanding  by  all  members  of  the 
team's  performance  objectives.  Effective  teams  are  characterised  by  a  commitment,  focus  and 
concentration  on  clearly  defined  goals.  Team  goals  should  be  believed  to  be  worthwhile,  and  personally 
challenging.  Their  pursuit  should  create  a  sense  of  urgency  and  progress.  Achievement  of  team 
objectives  should  make  a  clear  difference  to  the  situation.  Failure  of  teamwork  is  most  commonly 
caused  by  the  elevation  of  other  goals,  usually  personal  or  political,  above  the  team's  performance 
objectives.  Personal  and  political  agenda  threaten  the  clarity  of  team  goals,  leading  to  loss  of  focus  and 
reduced  concentration  of  team  efforts.  Achievement  of  objectives  can  be  facilitated  by  the  setting  of 
high,  but  achievable,  performance  standards,  which  motivate  and  produce  pressure  on  team  members 
to  improve  both  individual  and  team  performance. 

3.2  TEAM  GOALS  :  HUMAN-ELECTRONIC  CREW  ISSUES 

When  considering  the  design  of  a  goal-based  team  structure,  it  is  necessary  to  make  the  distinction 
between  goals,  sub-goals,  and  meta-goals.  Goals  are  the  teams  objectives,  successful  attainment  of 
which  are  both  necessary  and  sufficient  for  task  completion.  Sub-goals  refer  to  the  lesser  objectives, 
attainment  of  which  are  necessary  but  not  sufficient  for  task  completion.  Sub-goals  are  relevant  where 
achievement  of  mission  goals  requires  a  staged  or  iterative  process,  with  the  sub-goals  being  the 
objectives  of  each  stage  (SIMON,  1 978).  Meta-goals  refer  to  over-riding  goals  which,  although  not 
being  directly  related  to  the  task,  provide  an  infrastructure  in  which  successful  goal  achievement  can 
occur.  An  example  of  a  meta-goal  is  the  maintainance  of  pilot  situational  awareness.  Although  it  is  not 
part  of  the  mission,  per  se,  it  is  an  important  factor  in  the  pilot's  ability  to  reach  task  goals.  Failure  to 
achieve  such  a  meta-goal  will  impact  on  task  performance.  Thus  meta-goals  are  most  relevant  during 
the  design  stage,  be  it  the  design  of  systems  or  team  structures. 

When  team  structures  are  functioning  in  a  dynamic  environment  then  sub-goals  (and  to  a  lesser 
extent  task  goals)  will  change  (LIND,  1 988).  For  effective  team  performance,  all  team  members  must 
be  aware  of  any  changes  in  their  goals.  Failure  to  communicate  such  changes  will  result  in  the  loss  of 
the  common  goal  structure.  The  impact  of  this  for  the  design  of  human-computer  teams  is  that  such 
communication  must  be  bidirectional  i.e.  sufficient  feedback  must  be  given  by  both  team  members  for 
the  other  to  maintain  his  awareness  of  the  new  goals. 

4.  TEAM  RESOURCES 
4.1  TEAM  RESOURCES  :  SOCIAL  HEURISTICS 

Team  resources  comprise  all  the  relevant  abilities  and  tools,  skills,  rules  and  knowledge  available 
to  perform  the  task,  including  both  human  and  machine  capabilities.  The  availability  of  resources  is 
determined  by  the  team  size,  i.e.  the  number  of  individual  members,  by  the  level  of  individual  and  team 
training,  competence  and  expertise,  and  by  situational  factors  such  as  fatigue,  boredom  and  anxiety 
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slress.  Increasing  team  size  may  facilitate  or  inhibit  performance  on  tasks,  e.g.  by  generating  more 
ideas  on  problem  solving  tasks,  whilst  increasing  the  time  taken  to  generate  each  idea.  Resources  may 
be  redundant  or  unique,  through  the  team  being  composed  of  homogeneous  or  heterogeneous 
membership.  Homogeneity  for  some  resources  may  be  more  effective  for  performance  than 
heterogeneity.  However,  resource  variability,  through  heterogeneity  may  produce  greater  sensitivity 
to  changing  task  demands.  The  resources  must  be  willing  and  able  to  collaborate  effectively. 

Compatibility  can  be  achieved  with  different  but  complementary  resources  for  dimensions  such  as  the 
need  to  dominate  or  to  control  events.  Teamwork  is  normally  associated  with  the  achievement  of 
specific  goals  requiring  specialised  skills.  For  effective  teamwork,  the  requisite  resources  should  be 
available  and  appropriately  distributed  among  the  team  members,  in  accordance  with  the  task  structure 
and  load.  In  tasks  where  the  performance  of  a  team  is  limited  by  the  weakest  member  (conjunctive 
task  constraints),  resource  variability  is  undesirable.  In  tasks  where  team  performance  is  determined 
completely  by  the  best  member's  performance  (disjunctive  task  constraints),  a  high  degree  of  resource 
variability  is  desirable.  Matching  of  resource  characteristics  to  task  demands,  in  terms  of  the 
difficulty  of  underlying  operations,  is  the  key  to  estimating  the  capability  for  effective  teamwork. 

4.2  TEAM  RESOURCES  :  HUMAN-ELECTRONIC  CREW  ISSUES 

The  design  of  the  human-computer  team  requires  that  knowledge  be  gained  of  the  resources  of  each 
team  member.  This  will  allow  the  a  priori  allocation  of  tasks  to  that  member  best  fitted  to  perform 
them  (where  expertise  is  limited  to  one  member)  or  dynamically  according  to  the  situational  demands 
(where  both  members  have  relevant  expertise).  Correct  utilisation  of  unique  and  redundant  resources 
will  produce  a  synergistic  team,  thus  extending  the  total  resources  of  the  team  (MOSS  et  al,  1984).  An 
example  where  unique  resource  allocation  would  be  effective  is  in  judgements  under  uncertainty. 

Humans  are  traditionally  poor  at  integrating  multiple  sources  of  probabilistic  information  in  a  formal 
statistical  manner.  Computers  are,  on  the  other  hand,  good  at  such  ’number  crunching*  activities.  Thus 
a  successful  team  would  use  the  computer  resource  to  achieve  this  part  of  the  process.  Humans  are 
good,  however,  at  accepting  integrated  advice  and  using  heuristics  to  make  judgements  under 
uncertainty.  Thus  the  team  would  use  this  human  resource  to  complete  the  decision  process.  Where  both 
team  members  have  the  expertise  and  resources  to  perform  a  function,  then  allocation  of  that  function 
should  be  performed  dynamically,  with  the  choice  of  who  should  do  the  task  being  decided  through 
consideration  of  meta-goals  e  g.  maintainance  of  SA,  reduction  of  pilot  workload  etc.  The  design  of 
suitable  task  structures  to  best  exploit  the  available  resources  is  discussed  below. 

5.  TEAM  STRUCTURE 

5.1  TEAM  STRUCTURE  :  SOCIAL  HEURISTICS 

Team  structure  concerns  the  relatively  stable  pattern  of  relationships  between  members  that 
determines  the  communication  required  for  co-ordination  of  activities,  and  that  governs  the 
distribution  of  functions,  roles,  status  and  power.  The  function  of  team  structure  is  to  implement 
access  to  task-relevant  resources.  Team  structure  and  associated  patterns  of  communication  should  be 
designed  to  facilitate  rather  than  restrict  access.  Effective  teamwork  requires  a  structure  driven  by 
performance  results.  The  required  structure  is  that  which  is  appropriate  for  achievement  of  the 
specific  team  performance  objectives,  with  the  minimum  complexity  of  resources  necessary  and 
sufficient  for  successful  functioning.  Maintenance  of  organisational  processes  should  not  consume 
unnecessary  resources.  In  an  functionally  effective  structure,  individual  and  team  efforts  always  lead 
towards  achievement  of  the  team  goal.  Increasing  cohesiveness  and  attraction  between  team 
participants  leads  to  greater  conformity  to  team  norms,  more  uniformity  of  behaviour,  improved 
performance  and  increased  job  satisfaction.  Poor  performance  and  morale  are  associated  with  poor 
cohesiveness  and  low  membership  attractiveness.  Centralisation  of  communication  structure  affects 
membership  satisfaction  and  team  performance.  More  centralised  communication  networks  (e.g.  wheel 
versus  circle  structure)  produce  better  team  performance  but  lower  membership  satisfaction,  except 
in  complex  tasks  when  the  central  elements  become  overloaded.  Decentra  Used  networks  allow  a  more 
even  distribution  of  workload. 

Structure  creates  role  differentiation.  Status  and  power  are  affected  by  roles  and  functions. 
Discrepancy  between  the  expected  role,  perceived  role  and  enacted  role  of  individuals  introduces 
conflict  between  team  members.  The  evaluation  attached  to  a  role  determines  the  status  of  the 
individual  and  influences  conformity  to  team  norms.  The  perception  that  interactants  have  equal  status 
facilitates  communication.  Function  allocation  is  essential  for  effective  co-ordination  of  goal-  oriented 
activities.  A  high  degree  of  rigidity  and  clarity  in  function  allocation,  with  clear  accountabilities,  is 
beneficial  for  well-structured  tasks,  which  follow  a  clearly  defined  plan,  and  for  tasks  requiring  unique 
rather  than  redundant  resources.  Flexibility  in  function  allocation  is  beneficial  for  tasks  involving 
ill-structured  problems,  uncertainty  and  requiring  good  communication  between  team  members.  The 
communication  structure  influences  the  distribution  of  information,  power  and  authority  in  teams.  The 
member  through  which  most  information  passes  has  the  potential  to  exert  considerable  influence  over 
the  team  (informational  power)  In  a  highly-centralised  communication  structure,  the  member  in  the 
central  role  acts  as  the  information  gate  keeper  This  member  is  most  likely  to  be  perceived  as,  and 
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act  as,  the  team  leader.  The  distribution  and  locus  of  power  depends  on  the  ability  to  monuoi  me 
performance  of  members  and  to  exercise  reward,  coercion  and  feedback  (reward  and  coercive  power), 
to  generate  a  positive  image  that  attracts  emulation  (referent  power)  and  by  the  ability  to  internalise 
goal-relevant  information  and  acquire  knowledge  (expert  power).  Effective  teamwork  is  most  likely  to 
occur  when  assigned,  legitimate  power  coincides  with  the  locus  of  informational,  expert,  referent, 
reward  and  coercive  power.  The  function  of  the  team  leader  is  to  exercise  authority  and  power  in  order 
to  achieve  the  team's  performance  objective.  Leadership  is  achieved  by  changing,  directing  and 
controlling  the  behaviour,  attitudes  and  opinions  of  team  members  to  conform  with  team  roles, 
standards,  norms,  and  goals.  Leadership  behaviour  includes  clarifying  team  objectives,  making 
important  decisions  and  taking  initiatives,  and  identifying  ways  of  achieving  objectives.  Leadership 
effectiveness  is  dependent  on  the  exercising  of  situationally  appropriate  task-oriented  and 
relationship-oriented  skills.  A  strongly  authoritarian,  task-oriented  style  is  not  necessarily  the  most 
productive  when  dealing  with  ill-structured  tasks  requiring  good  communication  and  cohesiveness 
between  members. 

5.2  TEAM  STRUCTURE  :  HUMAN-ELECTRONIC  CREW  ISSUES 

The  implementation  of  the  structures  described  above  in  the  human-computer  team  require 
consideration  of  the  levels  of  autonomy  to  be  assigned  to  the  computer's  functions.  Several  taxonomies 
of  the  levels  of  autonomy  of  human-computer  interaction  have  been  postulated  le  g.  SHERIDAN  & 
VERPLANCK,  1 978).  They  describe  the  level  of  interaction  as  varying  from  the  human  performing  all 
functions,  through  increasing  levels  of  computer  autonomy,  to  the  computer  performing  functions 
independently  with  discretionary  power  to  not  inform  the  human.  The  level  chosen  is  likely  to  be 
situationally  dependent  in  that  it  will  depend  on  the  demands  of  both  goals  and  meta-goals.  This  is  since 
the  requirement  for  autonomy  is  itself  a  dynamic  function  of  the  operational  context.  For  efficient 
teamwork,  the  locus  of  power  should  be  allocated  to  maximise  goal  achievement.  An  example  would  be 
the  computer  Taking  control’  when  the  pilot  suffers  G-induced  loss  of  consciousness.  Also,  where  the 
computer  controls  data  fusion  and  displays  management  e.g.  Pilot's  Associate,  and  hence  information 
flow,  then  this  necessitates,  by  implied  consent,  that  at  least  part  of  the  leadership  role  (traditionally 
associated  with  the  human  team  member)  will  be  performed  by  the  computer  team  member. 

Where  task  allocation  is  static,  the  level  of  interaction  can  be  chosen  a  priori.  Dynamic  task 
allocation  may  require  a  variable  authority  gradient  to  exist  in  order  to  best  exploit  the  resource 
distribution  across  team  members.  Where  situational  demands  are  high,  requiring  pilot  mandate  for  all 
tow  level  'chores'  may  decrease  the  usefulness  of  assigning  such  tasks  to  the  computer.  When  the 
demand  is  less,  then  less  autonomy  may  be  beneficial  by  maximising  the  degree  to  which  the  pilot  is  'in 
the  loop’.  The  degree  to  which  this  is  relevant  is  likely  to  depend  on  the  types  of  functions  which  the 
computer  can  perform,  and  also  on  the  degree  of  trust  in  the  computer  exhibited  by  the  human.  Where  a 
high  degree  of  trust  is  available,  task  leadership  functions  may  be  shared  or  even  transferred  to  the 
computer  member.  How  such  levels  of  trust  can  be  produced  are  discussed  in  the  next  section. 

6.  TEAM  PROCESSES 

6.1  TEAM  PROCESSES  :  SOCIAL  HEURISTICS 

Team  processes  of  communication  and  interaction  are  affected  by  the  structural  characteristics  of 
the  team  (roles,  status,  cohesiveness).  Communications  can  be  analysed  for  functional  content  and 
style.  Content  can  be  task  oriented  or  social-emotional  oriented.  Task-oriented  communication 
includes  interactions  exchanging  information  (repetition,  confirmation,  clarification),  opinions 
(evaluation,  analysis,  feelings)  and  direction  (suggestions,  possible  actions).  Communication  with 
social-emotional  orientation  involves  positive  and  negative  reactions  concerning  agreement 
(acceptance,  concurrence,  understanding),  satisfaction  (release  of  tension,  humour)  and  solidarity 
(affirmation  of  status,  help,  reward).  Social  cohesiveness  is  important  for  team  productivity  and 
performance.  Interactive  styles  can  be  characterised  as  affiliative-nonaffiliative,  affecting 
cohesiveness  and  reflecting  attractiveness;  dominant-submissive,  reinforcing  power  relationships  and 
reflecting  status;  responsive-unresponsive,  reflecting  the  expressive  quality  and  effectiveness  of 
communication.  Communication  has  temporal  and  bandwidth  constructs  (channels,  modalities) 
Un-restricted  communication  can  be  unproductive,  distracting  and  an  inefficient  utilisation  of 
resources.  Broadening  the  communication  bandwidth  increases  the  psychological  closeness  of 
interactants.  However,  some  psychological  distance  may  be  necessary  for  tasks  requiring  autonomy 
and  independence  of  thought  and  action.  Widening  the  bandwidth  beyond  that  needed  for  audio 
communication  does  not  improve  performance  on  some  problem-  solving  tasks.  The  communication 
bandwidth  should  be  necessary  and  sufficient  for  achievement  of  team  goals.  Formal  language  can  be 
restrictive,  stow  and  inefficient  for  solving  ill-structured  problems.  Conformity  to  dialogue  protocols 
(e  g.  rules  for  structuring  tum-taking,  transferring  controls)  should  increase  the  efficiency  of 
communication  and  maintain  the  goal-orientation  of  interactions.  Effective  communication  requires 
knowledge  of  the  functionality,  meaning  and  goal  of  the  communication.  This  is  achieved  by  tracking 
both  the  goal  and  the  context  of  the  communication,  using  domain-specific  information  and  information 
for  the  control  of  the  communication  process.  Effectively  communicating  and  collaborating  teams  are 
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characterised  by  a  high  degree  of  trust.  Trust  requires  predictability,  dependability  and  faith  in 
interpersonal  relationships.  Trust  occurs  in  a  collaborative  climate  characterised  by  honesty, 
openness,  consistency  and  respect.  Violations  of  trust  have  catastrophic,  irredeemable  effects  on  team 
functioning  and  performance.  Full  teamwork  ootential  is  unlikely  to  be  realised  when  trust  has  been 
broken.  Trust  allows  team  members  to  stay  problem-focused,  it  promotes  efficient  communication  and 
co-ordination,  improves  the  quality  of  collaborative  outcomes,  and  it  leads  to  compensatory  behaviour. 
Compensation  between  ;ndividuals  is  necessary  for  performance  standard  to  ^  independent  of 
variability  in  team  resources. 

b.t  TEAM  PROCESSES  :  HUMAN-ELECTRONIC  CREW  ISSUES 

Communication  between  the  human  and  computer  team  members  is  achieved  through  the  design  of 
the  interface  between  them.  An  effective  interface  requires  an  understanding  of  the  knowledge 
requirements  of  the  team  members  with  a  consequent  moding  of  input/output  facilities  to  support  these 
requirements.  Again,  both  goals  and  meta-goals  need  to  be  considered  in  the  design  of  the  interface.  If 
the  computer  is  to  control  the  flow  of  information,  then  an  efficient  mode!  of  the  human’s  information 
processing  abilities/  requirements  is  essential.  Adaptive  or  learning  interfaces  have  the  rotential  for 
maximising  teamwork  (WEISBROD  et  al,  1977).  The  problem  with  such  systems  is  that  they  can  learn 
■bad  habits'  (or  sub-optimal  behaviours)  from  the  human  if  they  are  adapting  to  his  behaviour  without 
sufficient  reference  to  the  task  and  meta-goals.  They  need  to  be  goal  rather  than  behaviour  driven, 
implying  the  need  for  tho  adaptivity  to  be  bidirectional.  Ir,  other  words,  the  team  efficiency  will  ot.ly  be 
improved  where  human  and  computer  are  given  sufficient  feedback  on  goal  achievement  to  both  learn, 
and  hence  improve  sub-optimal  performance.  Such  feedback  will  not  only  allow  compensatory  teamwork 
to  occur,  but  will  also  enable  a  suitable  level  of  trust  to  develop  and  be  maintained.  Failure  to  o-ovide  it 
may  result  in  over-trusting  (EIMER,  1987b)  or  under-trusting  (LERCH  &  PRIETULA,  1989),  both  of 
which  impact  negatively  on  task  goal  achievement. 

7.  TEAMWORK  MATURITY  AUDIT 

It  may  be  useful,  on  the  basis  of  the  foregoing  analysis,  to  construct  a  tool  for  evaluating  and 
auditing  the  quality  and  maturity  of  teamwork  in  candidate  Human-Electronic  Crew  systems.  Table  1 
identifies  potential  audit  constructs  associated  with  teamwork  maturii> ,  derived  from  the  teamwork 
model  components.  In  conducting  an  audit  on  a  candidate  system,  the  aim  would  be  to  evaluate  the 
extent  to  which  the  audit  constructs  are  primary  features,  minor  features,  or  not  represented  in  the 
system  Additional  constructs,  from  other  domains  e  q.  systems  architecture,  software  engineering 
etc  would  need  to  be  incluoed  in  a  fully  comprehensive  analysis. 


MATURITY  CONSTRUCTS 

DEFINITIONS 

TEAM  GOALS 

Clarity 

Clearly  defined  performance  objectives. 

Common  Structure 

Shared  understanding  of  meta/sub  goals. 

T  racking 

Awareness  of  changing  objectives. 

Impact 

Critical  for  mission  success. 

Achievement 

High  probability  of  success. 

TEAM  RESOURCES 

Sufficiency 

Enough  expertise/ability/competence. 

Availability 

Readiness  for  application  to  task. 

Heterogeneity 

Variability/uniqueness  of  expertise. 

Compatibility 

Ability  to  combine/integrate/match. 

Enhancement  Capability 

Ability  to  add  to  expertise. 

TEAM  STRUCTURE 

Goal  Driven 

Governed  by  performance  objectives. 

Resource  Accessibility 

Facilitates  access  to  resources. 

Cohesiveness 

Attracts  conformity  to  team  norms. 

Dynamic  Function  Allocation 

Real-time  role/task  distribution. 

Levels  of  Autonomy 

Degrees  of  independent  functioning. 

TEAM  PROCESSES 

Wide  Bandwidth 

Multiple  modalities  for  communication. 

Bidirectionality 

Two-way  flow  of  information/feedback. 

Shared  Initiative 

Leadership  turn-taking. 

Common  Knowledge  Base 

Shared  understanding  of  situations. 

T  rust 

Willing  to  accept  others’  judgements. 

TABLE  1  -  Prototype  Teamwork  Audit  Tool 
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8.  CONCLUSIONS 

This  analysis  demonstrates  that  there  is  substantial  understanding,  in  social  psychology,  of  the 
processes  of  teamwork,  sufficient  to  generate  a  potentially  extensive  list  of  criteria  for  judging  the 
quality  and  maturity  of  Human-Electronic  Crew  teamwork  The  limitations  of  the  model  are  that 
Human-Electronic  Crew  teamwork  may  have  unique  emergent  characteristics  that  are  not  evident  from 
analysis  of  human  teamwork.  A  major  problem  with  the  model  is  that  it  is  based  on  a  high  degree  of 
trust.  When  distrust  occurs,  teamwork  breaks  down  in  a  potentially  catastrophic  and  irredeemable 
manner.  This  may  result,  in  the  worst  case,  in  the  human  operator  refusing  to  use  any  of  the  electronic 
crewmember's  capabilities.  The  distribution  of  power  raises  the  issue  of  leadership,  with  consequent 
moral  and  political  implications  if  the  locus  of  power  is  not  to  reside  with  the  human.  Such  a  prototype 
model  is  unlikely  to  provide  a  fully  comprehensive  analysis  of  the  issues.  However,  the  aim  of  audit  is 
to  judge  the  whole  through  a  sample  of  relevant  criteria.  As  such,  this  model  may  have  some  utility,  at 
least,  in  conceptualising,  designing,  and  validating  candidate  Human-Electronic  Crew  teams. 
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SUMMARY 

This  paper  discusses  what  we  feel  are  some  of  the  important  issues  ;n  designing  the  interface 
between  a  pilot  and  an  electronic  crewmember,  and  describes  some  of  the  problems 
encountered  in  addressing  them.  We  also  describe  some  possible  approaches  to  overcoming 
these  problems. 

1.  INTRODUCTION 

The  past  several  years  have  seen  a  number  of  efforts  to  develop  intelligent  pilot  aids.  They 
may  be  called  electronic  crewmembers,  pilot's  associates,  pilot's  assistants,  or  something 
else.  These  projects  differ  in  scope,  with  some  designed  for  more  or  less  functionality  than 
others;  in  breadth,  with  some  concentrating  on  entire  missions  and  others  on  particular 
segments;  or  in  application,  with  some  intended  for  commercial  aviation  purposes  and  others 
tailored  for  military  missions.  System  similarities  (such  as  functionality)  outweigh 
differences,  however,  and  their  developers  tend  to  share  a  set  of  fundamental  concerns.  Goals 
of  many  of  these  systems  include  offering  situation  assessment  advice,  planning  missions  and 
tactics,  monitoring  system  status,  offering  reconfiguration  advice  following  system 
malfunctions,  intelligently  managing  displays  (presenting  the  right  information  in  the  right 
form  at  the  right  time  without  burdening  the  pilot  with  system  management  tasks),  and 
recognizing  when  the  pilot  can  use  automation  help  (due,  for  example,  to  high  workload)  in 
order  to  allocate  functions  dynamically. 

Pilot-Vehicle  Interface  concerns  are  of  overriding  importance  in  such  a  system.  All  this 
functionality  will  be  just  another  black  box  if  it  is  not  implemented  properly.  The  present 
paper  describes  what  we  feel  are  some  of  the  important  issues  in  interface  design,  as  well  as 
some  of  the  problems  encountered  in  addressing  them.  We  also  describe  some  possible 
approaches  to  overcoming  these  problems. 

2.  MISSION  CONTEXT  AND  PILOT  INTENT 

One  outstanding  problem  for  an  intelligent  system  involves  determining  operator  (or  pilot,  in 
the  context  of  electronic  crewmembers)  intent.  The  concept  of  determining  intent  is  a  source 
of  confusion  and  controversy.  The  term  is  not  meant  to  imply  some  sort  of  mindreading. 

There  are  realistic  ways  to  determine  pilots'  most  reasonable  or  likely  actions  in  a  given  set 
of  circumstances,  and  the  challenge  is  to  make  them  work.  The  potential  payoff  is  high;  there 
are  many  advantages  to  achieving  a  precise,  robust,  predictive  scheme  for  inferring  intent, 
particularly  in  the  kind  of  dynamic  environment  a  cockpit  represents.  These  include  likely 
improvements  in  system  performance  as  a  result  of  anticipating  a  pilot's  information  and 
function  allocation  needs,  and  reducing  the  need  for  direct  pilot-system  communication. 

Most  previous  attempts  to  infer  pilot  intent  have  adopted  traditional  Artificial  Intelligence 
techniques  and  knowledge  acquisition  methods,  and  depend  on  rulebases,  scripts,  and  the 
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like.  Ii  has  never  been  clear  that  these  adequately  capture  the  subtleties  of  the  environment 
sufficiently;  sceptics  (e.g.,  Dreyfus  &  Dreyfus,  1986)  argue  that  procedural  rules  and  scripts 
are  insufficiently  flexible  to  represent  cognitive  activities  in  complex  environments.  A 
rulebase  may  always  need  yet  another  conditional  statement  to  handle  new  circumstances.  In 

response  to  these  problems,  some  electronic  crewmember  systems  adopt  the  tactic  of  making 
relatively  loose  predictions  about  intent  and  relying  for  their  accuracy  on  monitoring  the 
pilot's  actions  to  confirm  or  disconfirm  and  reconfigure  predictions.  In  a  sense,  this 
approach  can  be  considered  as  much  reactive  as  predictive.  It  can  also  be  very  cumbersome 
and  expensive  to  build  a  system  based  on  this  approach  and  difficult  to  modify  or  tailor  it  to 
individual  preferences. 

Alternatives  are  available,  however,  for  acquiring  and  representing  both  the  knowledge  and 
the  policy  that  pilot  intent  implies.  We  are  exploring  the  feasibility  of  using  statistical 
models  (e.g.,  through  discriminant  analysis)  of  the  relationship  between  the  " mission 
context",  expressed  as  a  set  of  pertinent,  measurable  aspects  of  the  mission  environment  (and 
perhaps,  if  necessary,  some  minimal  set  of  observable  pilot  actions),  and  a  pilot’s  probable 
physical  and  cognitive  tasks.  For  example,  a  threat  encounter  might  be  represented  in  terms 
of  the  type  of  threat,  the  distance  from  ownship,  assessments  of  its  intent  and  capabilities, 
numbers  and  types  of  ownship  defenses  and  countermeasures,  and  the  like.  Using  expert 
judgments  or  data  from  simulated  flight,  the  patterns  these  variables  represent  could  be 
grouped  and  mapped  onto  a  set  of  response  tactics.  The  analytic  component  of  this  approach  is 
very  much  like  "cognitive  task  analysis"  (e.g.,  Terranova,  Snyder,  Seamster,  and  Treitler, 

1989),  but  the  resulting  model  would  be  very  similar,  both  conceptually  and  mathematically, 
to  a  "neural  net",  (Rumelhart,  McClelland,  and  the  PDP  Research  Group,  1986).  (Indeed,  a 
neural  net  might  be  used  instead  of  discriminant  analysis.)  Similarly,  regression  equations 
could  be  developed  from  prioritized  ratings  of  information  requirements  to  support  the  tasks 
appropriate  for  each  example  context  or  group  of  contexts.  An  alternative  approach  to 
modeling  the  pilot's  judgments  about  tactics  and  related  decisions  would  involve  using  "policy 
specifying"  techniques  (Ward,  1977). 

This  context-based  approach  is  promising,  but  has  yet  to  be  adequately  developed  and  tested. 
If  successful,  it  might  offer  several  advantages  over  current  methods,  providing  the  system 
with  a  flexible  representation  of  the  pilot's  likely  actions  and  requirements  in  virtually  any 
context. 

3.  DECISION  SUPPORT/DISPLAY  MANAGEMENT 

Pilots  are  confronted  with  a  numbing  amount  of  information  from  sophisticated  current 
avionics  systems,  and  new  avionics  are  planned  all  the  time,  especially  for  military 
applications.  For  the  most  part,  professional  pilots  are  able  to  pick  out  and  absorb  the 
information  they  require  at  any  given  time.  But  it's  not  made  very  easy.  One  frequent 
complaint  is  that  to  make  the  cockpit  environment  tolerable  some  of  the  avionics  and  warning 
systems  intended  as  important  and  helpful  in  maintaining  situational  awareness  must  be 
turned  off.  The  important  point  is  that  an  electronic  crewmember  can't  be  viewed  as  just  so 
much  additional  functionality. 

One  way  of  assuring  during  the  design  process  that  this  doesn't  happen  is  to  view  the 
electronic  crewmember  as  a  decision  support  system.  This  involves  expanding  upon  the  basic 
information  requirements  to  systematically  justify  the  functionality  of  the  system.  Zachary 
(1988),  for  example,  has  developed  a  complete  framework  for  evaluating  decision  support 
needs  by  considering  both  the  decision  maker's  objectives  and  the  environment  in  which 
decisions  are  to  be  made.  In  other  words,  it  is  important  to  consider  not  just  what  information 
is  required,  but  also  what  will  be  done  with  it.  The  process  continues  in  order  to  determine 
how  the  information  must  be  analyzed  to  be  most  useful. 

Another  way  of  aiding  the  pilot's  decision  making  includes  systematically  determining  when 
and  how  the  system's  products  are  presented.  This  allows  the  designer  to  implement 
intelligent  display  management  techniques  with  the  goal  of  reducing  the  system  management 
tasks  required  to  configure  displays.  Thus,  when  the  pilot  is  performing  some  task,  a  display 
format  would  be  selected  to  support  the  task  with  information,  tailored  in  both  content  and 
modality  according  to  his/her  current  workload  level  and  other  pertinent  factors. 
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Conceptually,  intelligent  display  management  is  a  special  case  of  dynamic  function  allocation, 
which  is  discussed  further  in  the  following  section. 

4.  DYNAMIC  FUNCTION  ALLOCATION 

Function  allocation  analysis  is  fundamental  to  the  design  of  any  cockpit,  and  frameworks  for 
such  analyses  have  become  very  sophisticated  (e.g.,  Pulliam  &  Price,  1985).  In  general, 
though,  three  basic  questions  are  typically  asked  when  static  systems  are  being  designed: 
what  does  the  person  do  best,  what  does  automation  do  best,  and  what  can  either  one  do? 

General  descriptions  of  tasks  that  fall  into  each  category  have  been  around  for  a  long  time. 
Building  an  electronic  crewmember,  however,  allows  for  the  possibility  of  dynamic  function 
allocation  (DFA). 

Briefly,  the  idea  of  DFA  is  that  an  intelligent  system  can  itself  determine  the  need  for 
automating  more  or  fewer  tasks  without  the  pilot's  explicit  authorization.  DFA  is 
controversial  and  many  pilots  find  the  notion  distasteful  because  they  assume  it  will 
necessarily  disrupt  the  basic  understanding  that  a  pilot  has  of  his/her  own  responsibilities 
and  the  aircraft's.  For  proponents,  however,  it  constitutes  an  absolute  requirement  for 
building  a  true  electronic  crewmember,  or  an  "associate"  for  the  pilot.  The  real  issue  appears 
to  be  whether  DFA  can  be  implemented  so  as  to  retain  system  predictability,  the  pilot  must 
understand  the  system  well  enough  to  know  what  it  will  or  won't  do  at  any  given  time. 

In  addition,  as  Chinnis,  Cohen,  &  Resnick  (1984)  note,  it  may  not  be  sufficient  to  analyze  how 
a  job  is  presently  done  and  allocate  pre-existing  cognitive  tasks.  First,  adding  an  electronic 
crewmember  can  change  the  very  nature  of  the  tasks,  so  a  simple  allocation  scheme  can 
perpetuate  an  existing  inferior  approach.  Second,  the  nature  of  how  tasks  are  performed 
changes  in  a  dynamic  environment.  For  example,  the  decision-making  process  in  stressful  or 
time-constrained  situations  can  be  very  different  from  that  during  more  relaxed  periods  (c.g.. 
Noble,  1989).  Thus,  people  may  be  better  than  computers  under  one  set  of  circumstances,  but 
no  better  or  even  worse  than  computers  under  other  circumstances.  The  lesson  for  someone 
making  function  allocation  decisions  is  obvious.  The  first  step  should  be  to  consider 
allocations  in  terms  of  what  variables  make  a  particular  allocation  desirable.  The  next  step 
should  be  to  consider  how  various  mission  events  could  affect  those  variables. 

Fortunately,  "dynamic"  does  not  mean  "chaotic";  of  course  we  can't  allow  just  anything  to 
happen  at  any  time.  The  goal  is  to  emulate  a  perfect  backseater  or  copilot,  with  whom  the  pilot 
has  worked  for  a  long  time.  Each  knows  what  needs  to  be  done  and  what  each  can  decide  to  do. 
The  backseater  may  not  need  to  be  told  to  do  something,  but  instead  can  recognize  the  need,  do 
it,  and  tell  the  pilot  it's  done  with  a  brief  message. 

DFA  will  need  to  be  applied  very  carefully,  however,  and  only  after  investigation  to  determine 
the  circumstances  in  which  it  should  occur,  how  to  let  the  pilot  know  it  is  occurring,  and  just 
how  tasks  should  in  fact  be  allocated  dynamically.  We  are  already  working  on  a  way  of 

triggering  and  directing  DFA  based  on  a  real-time  estimate  of  pilot  task  demands;  when 
completed,  it  will  require  calibration  and  development  of  a  policy  for  its  use.  Other  factors 
should  reasonably  affect  allocation  decisions  as  well,  such  as  system  workload  and 
capabilities,  and  the  time  required  for  the  pilot  to  absorb  and  understand  displays.  Although 
Chechile,  Eggleston,  Fleischman,  and  SasseviJle  (1989)  have  reported  work  on  measuring  the 
"cognitive  content"  of  displays,  making  any  such  model  useful  also  involves  relating  the 
model  s  outputs  to  actual  performance  or  comprehension  across  a  range  of  workload  levels. 

5.  SYSTEM  AUTONOMY 

System  autonomy  is  an  issue  closely  related  to  DFA.  The  first  comprehensive  introduction  of 
an  electronic  crewmember  into  the  cockpit  will  also  face  critical  issues  of  how  much  autonomy 
it  should  exercise,  when  it  should  take  over  tasks,  whether  it  should  override  the  pilot  (and  if 
so,  under  what  conditions),  and  so  forth.  Wrapped  up  in  these  questions  are  the  operational 
criteria  an  electronic  crewmember  must  satisfy:  it  must  be  predictable,  support  the  pilot's 
needs,  require  minimum  communication  and  supervision,  and  not  be  disruptive  by  changing 
displays  or  modes  or  taking  other  actions  against  the  pilot’s  wishes.  But  what  should  happen 
if  the  pilot  doesn't  recognize  the  need  for  assistance,  such  as  during  disorientation?  What 
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happens  if  the  pilot's  actions  don't  follow  the  crewmember's  expectations  based  on  its 
understanding  of  the  current  situation  and  plans?  What  happens  if  the  crewmember  can't 
form  an  adequate  situation  assessment  or  plan,  or  infer  the  pilot's  intent  with  a  high  degree  of 
confidence?  How  can  confusion  about  pilot/crewmember  responsibilities  be  avoided  in  a 
dynamic  function  allocation  environment?  Are  system  requirements  for  predictability 
compatible  with  the  desired  functionality? 

One  promising  approach  to  resolving  this  dilemma  is  to  provide  the  system  with  a  small, 
discrete  set  of  operational  modes  or  autonomy  levels.  Within  each  level  the  crewmember's 
authority  would  be  well-defined  and  bounded,  facilitating  predictability.  In  addition,  a  small 
number  of  well-defined  rules  could  describe  conditions  under  which  the  crewmember's 
autonomy  level  can  change  and  how  it  can  change.  The  philosophy  could  also  allow  the 
crewmember  to  provide  safety  functions  to  compensate  for  disorientation,  impairment,  or  work 
overload.  Finally,  it  could  provide  the  pilot  with  an  always-available  "panic  button" 
capability,  whereby  the  crewmember  could  recover  the  aircraft  to  a  safe  situation  while  the 
pilot  became  reoriented,  planned  the  next  action,  or  prepared  to  take  control  once  again. 

Within  this  framework,  we  need  to  determine  the  number  of  levels  that  are  suitable,  and  what 
the  functionality  within  each  level  should  be.  For  example,  there  might  be  an  "Inactive" 
mode;  at  this  level,  the  system  could  maintain  all  monitoring,  situation  assessment,  and 
planning  functions,  but  take  no  actions  and  initiate  no  pilot  communications.  In  "Standby" 
mode,  the  system  could  also  initiate  communication  with  the  pilot  when  some  pilot-defined 
condition  is  satisfied,  such  as  crossing  a  waypoint  or  encountering  a  threat.  As  an  "Advisor" 
the  system  would  provide  assessments,  plans  and  instructions,  but  take  no  actions.  As  an 
"Assistant”,  the  system  would  maintain  advisory  functions  and  also  assume  responsibility  for 
tasks  explicitly  allocated  to  it  by  the  pilot.  At  the  "Associate"  level,  full  DFA  would  be  in 
effect;  the  system  would  maintain  advisory  functions  and  responsibility  for  explicitly 
allocated  tasks,  but  would  also  take  over  tasks  as  needed,  based  on  mission  events,  the  current 
plan,  survivability  and  safety  assessments,  pilot  task  demands,  task  priorities,  and  pilot 
preferences. 

Any  framework  also  requires  a  clear  set  of  rules  regulating  autonomy  levels.  For  example,  the 
pilot  should  be  able  to  select  any  level  at  any  time.  In  addition,  if  the  system  cannot  perform 
at  the  selected  level  due  to  lack  of  information,  low  confidence  level,  or  because  of  a  fault,  it 
might  inform  the  pilot  of  the  reason  and  assume  the  highest  level  it  can.  If  control  tasks  are 
involved,  they  should  be  transitioned  back  to  the  pilot  based  on  pilot  preferences,  task 
priorities,  and  system  capabilities.  The  current  autonomy  level  should  always  be  displayed 
to  the  pilot,  and  perhaps  a  list  of  system-authorized  functions  should  be  available  for  display 

at  any  time,  or  constantly  if  the  pilot  chooses. 

Of  course,  a  lot  of  work  is  required,  particularly  developing  techniques  and  performing 
studies  to  measure  and  benchmark  pilot  and  system  capabilities,  establishing  criteria  and 
thresholds  for  changes  in  level  based  on  these  factors,  and  developing  a  pilot-  ehicle 
interface  concept  appropriate  for  managing  the  crewmember's  autonomy  level. 

6.  GENERAL  CONSIDERATIONS 

Electronic  crewmember  concepts  do  not  have  to  represent  quantum  leaps  in  development. 

Pilots  already  use  and  trust  automated  systems  for  a  number  of  purposes.  In  an  F-15,  for 
example,  if  the  radar  is  operating  in  long-range  search  mode  and  locks  on  to  a  target,  an 
automatic  display  reconfiguration  occurs;  if  missiles  mounted  on  the  right  wing  have  locked 
on  to  a  target  but  combat  maneuvers  bring  the  target  around  to  the  left  side  of  the  aircraft,  the 
lock  is  automatically  transferred  to  a  left-side  missile.  The  important  point  is  that  pilots 
accept  and  like  these  actions  because  they  are  the  same  thing  they  would  do  manually  under 

the  circumstances  and  the  automation  makes  their  lives  a  bit  easier.  They  also  involve  a 

rudimentary  form  of  dynamic  function  allocation.  The  question  is  whether  we  can  extend 
acceptance  and  trust  from  these  specific  functions  to  systems  that,  for  example,  offer  tactical 
advice  or  generally  automate  display  reconfiguration  and  a  wide  variety  of  functions. 

There  is  still  a  lot  we  need  to  learn  about  how  people  react  to  automated  systems  and  about 
how  people  fundamentally  interact  with  and  use  decision  aids.  In  an  interesting  paper. 
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Lehner,  Mullin,  and  Cohen  (1989)  argue  that  it  is  important  that  users  be  given  information  to 
help  them  "identify  contexts  in  which  (either  they  or  the  system)  is  likely  to  be  incorrect". 
They  raise  the  concern  that  not  doing  so  may  result  in  the  aid  contributing  to  worse,  not 
better,  decision  making.  On  the  other  hand,  decision  aids  may  be  useful  for  the  information 
they  supply  users  quite  apart  from  their  advice.  They  may,  for  example,  configure  and 
present  information  in  a  useful  way;  the  user  is  informed  even  if  the  ultimate  advice  is  not 
accepted.  This  is  our  final  point;  efforts  and  development  programs  don't  always  have  to 

work  out  as  expected  to  be  valuable. 
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ADAPTIVE  FUNCTION  ALLOCATION  FOR 
INTELLIGENT  COCKPITS 

LCOR  John  E.  Don ton 
Naval  Air  Development  Cantor 
Narmins ter ,  Pennsylvania 

SUMMARY 

The  trend  toward  the  automation  of  aircraft  systems  haa  increaaed  aa  the 
threats  and  mission  functions  of  modern  tactical  aircraft  increase  in 
complexity.  Advances  in  computer  technology  and  artificial  intelligence 
systems  have  made  the  concept  of  cockpit  automation  a  viable  technology. 
This  trend  results  from  the  common  assumption  that  such  technology  will 
decrease  workload,  reduce  error,  and  expand  human  capabilities.  The  use 
of  these  technologies  is  essential  to  deal  with  the  ever  increasing 
information  processing  demands  of  complex  systems.  However,  several  human 
performance  issues  need  to  be  addressed  to  achieve  the  anticipated 
benefits  of  automated  cockpits.  The  Cockpit  Automation  Program  at  the 
Naval  Air  Development  Canter  (NADC)  was  developed  specifically  to  examine 
the  human  performance  aspects  of  the  "intelligent"  cockpit.  This  paper 
describes  the  program  at  NADC,  focusing  primarily  on  investigations 
planned  during  the  first  year's  effort. 

INTRODUCTION 

The  introduction  of  automation  technology  in  aircraft  has  given  rise  to 
new  human  factors  issues  and  concerns.  For  example,  the  ability  of  the 
pilot  to  intervene  effectively  when  an  automated  subsystem  fails  is  one  of 
the  key  issues  frequently  discussed  in  relation  to  automated  cockpits  (1). 
Other  difficulties  that  operators  of  automated  systems  may  face  include 
loss  of  system  awareness  and  manual  skills  degradation  (2).  Another  major 
issue  involves  the  degree  to  which  a  system  should  be  automated. 

Automation  can  be  thought  of  as  a  continuum  between  total  human  control, 
and  totally  autoomtic  control  (3).  A  specific  instance  of  automation  may, 
however,  include  a  degree  of  flexibility  where  the  allocation  of  control 
changes  in  a  dynamically  changing  environment.  That  is,  the  level  of 
automation  is  dynamic  and  remains  sdaptive  to  levels  of  workload  and/or 
critical  mission  events.  This  has  bean  termed  adaptive-aiding  and  has 
been  shown  to  be  effective  in  improving  performance  in  many  situations 
(4,5).  The  assumption  underlying  the  implementation  of  these  technologies 
is  that  with  the  automation  of  functions  thst  were  once  relegated  to  human 
control,  the  processing  resources  of  the  individual  will  be  freed  to  deal 
more  effectively  with  other  aspects  of  systems  requirements  (6).  However, 
while  the  use  of  these  technologies  is  essential  to  deal  with  the  ever 
increasing  information  processing  demands  of  complex  systems,  the  long¬ 
term  implications  of  these  technologies  on  human  performance  are  largely 
unknown  (7,0). 

Because  of  the  complexity  of  the  next  generation  tactical  aircraft,  the 
use  of  intelligent  crew  support  systems  is  becoadng  an  increasingly 
important  design  option.  For  example,  several  intelligent  systems  are 
being  introduced  into  the  sir  combat  environment.  The  Advanced  Tactical 
Fighter  (AT?)  and  its  Navy  counterpart  (MATF)  both  plan  to  incorporate 
automation  concepts  developed  as  part  of  the  Filot  Associate  Program.  The 
use  of  such  systems  is  s  necessity  because  of  increased  crew  information 
and  control  loading  (9).  Therefore,  the  question  is  no  longer  whether 
automation  should  be  introduced,  but  how  systems  should  be  designed  to 


optisii*  human  performance  in  tha  use  of  thaaa  aystama.  However  ,  tba  uaa 
of  auch  ayatama  could  aaaily  raault  in  performance  degradation  if  they  are 
not  deaigned  to  be  compatible  with  crew  requirementa  for  advanced 
crewatation  daaigna  (10). 


The  purpoae  of  the  NADC  Cockpit  Automation  Program  (CAP)  ia  to  examine  the 
human  performance  implieationa  of  the  intelligent  cockpit.  One  of  the 
moat  important  problem  areaa  to  be  addreaaed  ia  in  determining  the  taak 
conditiona  under  which  adaptive  automation  of  aircrew  aupport  ayatema  may 
be  beneficial.  Additionally,  our  program  will  examine  how  control  paaaea 
between  the  crew  and  computer.  The  nature  of  the  human-computer  interface 
for  adaptive  ayatema  ia  another  area  that  haa  not  received  much  attention. 
Aa  a  raault,  our  effort  will  develop  interface  deaign  techniguea  needed  to 
maintain  the  crew 'a  tactical  awarenaaa  and  give  them  the  feeling  of 
control  over  the  aircraft  miaaion.  While  many  of  theae  ldeaa  have  been 
diacuaaed  conceptually,  moat  have  not  been  ayatematically  evaluated.  It 
will  be  crucial  to  examine  theae  concepta  in  a  more  dynamic  aircraft/crew 
miaaion  environment  ao  that  the  principlea  reaulting  from  thia  reaearch 
can  be  operationally  defined  and  validated.  Therefore,  the  final  products 
of  the  program  will  be  cognitive  engineering  principlea  and  guidelinea 
suitable  for  documenting  specif icationa  for  future  Naval  air  platforms. 

PROGRAM  OVERVIEW 


The  CAP  is  a  four-year  effort,  initiated  in  FY90,  involving  personnel  at 
NADC  and  the  Navy  Reaearch  Laboratory  (URL)  aa  well  aa  technical  aupport 
from  both  academic  and  private  sectors.  In  general,  the  first  year 
examined  the  conditiona  under  which  adaptive  dec ia ion-aiding  was 
effective.  The  emphasis  during  thia  year  waa  to  define  and  demonstrate 
adaptive  processes  under  different  conditiona.  That  ia,  what  tasks  are 
suitable  for  adaptive  decision-aiding  and  under  what  conditiona  are  theae 
technologies  appropriate.  The  first  experiment  conducted  thia  year  waa 
developed  to  obtain  baseline  performance  measures.  Factors  auch  aa 
workload  level,  event  rate,  and  number  of  target  classifications  were 
factorially  combined  to  determine  appropriate  parameter  levela  for  the 
next  set  of  experiments.  The  second  experiment,  baaed  on  input  from  the 
baseline  study,  will  asaesa  how  individual  taak  components  (resource 
requireaMnta )  contribute  to  overall  performance  and  interact  in  their 
impact  on  each  of  the  other  component  tasks.  The  results  of  the  first 
year's  experiments  will  help  to  clarify  the  class  of  tasks  that  are 
amenable  to  adaptive  processing.  The  second  year  will  determine  what 
adaptive  control  processes  are  moat  efficient  under  different  tactical 
conditions.  Bare  the  main  area  of  interest  will  be  in  examining  the 
process  in  which  Information  ia  "handed-off"  between  the  human  operator 
and  the  computer.  The  third  year  will  include  the  development  of 
principlea  for  adaptive-aiding  in  the  intelligent  cockpit.  Drawing  on  the 
database  developed  in  the  first  two  years,  the  third  year  will  propose 
principlea  that  can  be  uaed  to  develop  the  characteristics  of  adaptive- 
aids  for  use  in  a  tactical  environment  auch  aa  air  coahit  maneuvering  or 
strike  warfare.  The  final  year  will  demonstrate  a  full  miaaion  simulation 
verifying  the  principlea  developed  in  the  third  year. 


BASELINE  EXPER 


i7,iy 


NT 


The  purpoae  of  the  first  experiment  waa  to  create  a  simulated  environment 
that  sampled  the  moat  important  cognitive  and  perceptual/motor  tasks 
present  in  a  high  performance  tactical  aircraft.  The  baseline  experiment 
was  conducted  using  the  MADC 'a  Recon figurable  Crewatation  (RC).  The  RC  is 
a  two-aeat,  non-motion  based  weapon  system  simulator  deaigned  to  be  able 
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to  simulate  currant  and  naxt  generation  display  and  weapon  tachnology. 

Tha  study  consistad  of  two  cora  tasks  that  wars  praaantad  on  two  aaparata 
multi-function  displays  in  tha  RC  cockpit*  tha  Tactical  Assessment  Task 
(TAT)  and  tha  Tracking  Task  (TT).  Tha  TAT  consistad  of  a  top-down  view  of 
a  tactical  situation  evolving  about  tha  owncraft  (saa  Figure  1).  Tha  TAT 
display  showed  multiple  target  symbol  types  (e.g.,  friendly,  hostile)  that 
ware  acquired  via  datalink.  Superimposed  on  tha  display  ware  two 
concentric  range  circles  centered  about  tha  owncraft.  Tha  outer  circle 
represented  tha  limit  of  the  owncraft  onboard  sensors.  The  inner  circle 
represented  tha  minimum  range  that  an  enemy  aircraft  was  permitted  to 
penetrate.  The  primary  task  required  of  the  subject  was  to  monitor  the 
TAT  and  respond  to  "events"  with  the  proper  button  press.  An  "event"  was 
defined  as  tha  time  at  which  a  datalink  target  appeared  within  the  area 
between  tha  two  concentric  range  circles.  The  targets  may  cross  over  the 
outer  circle  from  a  starting  location  outside  the  circle,  or  a  target  may 
simply  "pop-up"  in  the  middle  of  the  display.  One  of  two  button  presses 
were  required  of  the  subject  as  different  tactical  events  occurred  on  the 
display.  A  "Confirm"  button  press  was  used  for  friendly  type  symbols, 
while  the  "DESignate"  response  was  used  for  hostile  type  symbols. 


FIGURE  1 

TACTICAL  ASSESSMENT  TASK 


As  the  tactical  aituation  unfolded,  subjects  were  required  to  "fly"  the 
aircraft  via  the  TT.  The  TT  required  that  the  subject  perform 
compensatory  tracking  in  two  dimensions.  The  TT  presented  a  computer- 
driven  "target"  for  the  subject  to  follow  via  control  stick  inputr  (see 
Figure  2) . 
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FIGURE  2 
TRACKING  TASK 


For  the  TAT,  there  were  two  primary  experimental  variables i  (1)  number  of 
different  types  (classes)  of  symbols  presented,  and  <2)  the  event  rate  at 
which  targets  became  eligible.  Variation  of  the  number  of  different 
symbols  that  appeared  presumably  affected  the  memory  load  of  the  subject. 
Display  load  was  varied  through  different  event  rates  that  governed  the 
numfcar  of  stimuli  presented  on  the  screen  at  any  one  time.  The  primary 
aesjuro  of  performance  for  the  TT  was  RMS  error  between  the  owncraft  and 
tSu  target.  Subject  performance  for  the  TAT  consisted  of  amen  reaction 
tJ-cs®  fer  all  target  events.  Results  were  presented  in  terms  of  correct 
and  incorrect  responses,  missed  targets,  and  false  alanas.  Again,  the 
primary  purpose  of  the  baseline  study  was  to  determine  appropriate  levels 
of  voxWo ttd  as  design  considerations  for  the  next  set  of  studies. 

AOiiaXIONAL  EXPERIMENTS  PLANNED  FOR  FY90 

Tho  goal  of  the  next  group  of  studies  was  to  investigate  which  typma  of 
tasks  «ould  most  benefit  from  adaptive  automation,  i.e.,  where  will 
adopt  * vs  automation  result  in  the  most  improvement  in  pilot-aircraft 
Performance.  Secondly,  we  also  wished  to  study  potential  performance 
deficite  (the  "automation  deficit")  associated  with  automating  cockpit 
tasks.  The  rationale  for  this  work  relies  loosely  on  Pickens'  multiple 
resources  model,  which  decomposes  tasks  according  to  the  classes  of 
processing  resources  used  by  the  tasks.  The  experimental  approach  is 
b*  sad  on  a  generic  multi-tasking  context  consisting  of  a  communications 

r  the  TAT,  and  the  TT.  Each  experimental  condition  consisted  of  three 
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••rial  ngMnti,  such  that  tha  firat  and  last  aagMnta  required  the 
subject  to  perform  all  three  taafca  concurrently.  The  first  assent  in 
each  condition  was  the  baseline  segment,  enabling  a  baseline  measure  of 
performance  to  be  obtained  on  each  of  the  three  tasks.  The  nscond  segment 
in  each  condition  was  a  test  segment,  in  which  the  difficulty  of  one  of 
the  tasks  was  increased  with  or  without  autoamtion.  The  third  segment 
repeated  the  baseline  segment  and  allowed  the  estimate  of  the  "automation 
deficit,”  a  deficit  in  performance  level  due  to  the  prior  use  of 
automation.  This  basic  structure  allowed  investigation  oft  |1)  the 
effects  of  resource  competition  (by  compering  across  conditions  with  low 
common  resource  requirements  with  those  of  high),  (2)  automation  benefit 
(by  compering  Segment  2  automated  vs.  nonautomated) ,  end  (3)  automation 
deficit  (by  comparing  Segment  3  following  an  automated  segment  with  the 
baseline  Segment  1 ) .  Space  limitations  do  not  permit  detailed 
specifications  of  the  procedures  to  be  followed  in  this  experiment; 
however,  a  restatement  of  the  study's  hypotheses  should  prove  informative t 

HI .  Cognitive  tasks  show  a  greater  automation  deficit  than 
perceptual -motor  tasks. 

H2.  Cognitive  tasks  show  a  greater  automation  benefit  that, 
perceptual-motor  tasks. 

H3.  The  greater  is  the  resource  competition,  the  greater  ic 
the  automation  benefit. 

Another  experiment  is  planned  that  will  compare  automatic  versus  adaptive- 
aiding  in  a  typical  monitoring  situation.  The  question  to  be  answered 
here  is  in  determining  under  what  conditions  adaptive  processes  should  be 
invoked.  This  study  will  examine  the  relative  efficiency  of  fully 
automated  and  adaptively  automated  systems  under  various  levels  of 
workload  and  tims-on-task .  That  is,  how  will  various  levels  of  time-on- 
task  interact  with  workload  level  to  affect  the  aircrew's  ability  to 
monitor  automated  as  opposed  to  adaptively  aided  tasks  (such  as  responding 
to  changes  in  the  status  of  different  aircraft  systems) .  The  effects  of 
emergency  events  and  some  measure  of  overall  tactical  awareness  will  be 
important  experimental  factors  to  consider  when  analyzing  the 
effectiveness  of  various  levels  of  automation.  Another  important 
consideration  to  be  investigated  in  this  study  is  how  the  aircrew  uses 
adaptive  and  autosmted  systems  after  they  becosM  a  familiar  part  of  the 
flight  routine.  That  is,  will  subjects  become  over  dependent  upon 
automation  with  extended  practice?  Moreover,  it  will  be  important  to 
assess  whether  subjects  demonstrate  an  increase  in  tactical  awareness  with 
adaptive  as  opposed  to  fully  autoaiated  systems. 

CONCLUSION 

For  the  time  being,  the  human  operator  will  remain  an  integral  part  of  any 
Intelligent  cockpit,  if  only  to  serve  as  a  redundant  elemant. 

Additionally,  we  believe  that  ultimate  decision-making  responsibility  must 
lie  with  the  aircrew.  The  design  of  human-computer  interfaces  along  with 
the  development  of  suitable  models  to  predict  human  performance  under 
multi-task,  high  workload  environments,  will  undoubtedly  prove  to  be  the 
challenge  facing  the  engineer  and  human  factors  specialist  as  they  work 
together  to  design  advanced  combat  aircraft  of  the  future. 
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MISSION  MANAGEMENT  IN  GROUND  ATTACK  QPgRATTOMR 


THE  HUMAN  COMPOTgR  INTERPACE 

J.R.  Catford  (GEC  Avionics  Ltd) 

(On  Behalf  of  the  MMA  Joint  Venture  -  RAE  Farnborough  GU14  6TD) 


ABSTRACT 


The  Mission  Management  Aid  Joint  Venture  (MMA  JV)  is  a  collaborative 
research  project  between  British  Aerospace,  GEC  Ferranti  Defence  Systems, 
GEC  Avionics  and  GEC  Sensors,  Secretary  of  State  for  Defence  (RAE)  and 
Smiths  Industries  Aerospace  and  Defence  Systems.  The  management 
organisation  for  the  Joint  Venture  is  shown  in  figure  1.  The  Joint  Venture 
is  a  three  phase  programme,  the  objectives  of  which  are  to: 

i)  Establish  the  functional  requirements  and  feasibility  of  the 
MMA. 


ii)  To  prove  the  techniques  for  accomplishing  this  in  a  rapid 
prototyping  environment  and  produce  a  set  of  functional 
specifications . 

iii)  To  optimise  the  MMA  functionality  and  develop  the  MMI  on  a  real¬ 
time  Mission  Capable  Simulation  (MCS). 


With  the  ever  increasing  trend  towards  complex  integrated  avionics  systems 
and  the  increased  level  and  capability  of  threat  anticipated  in  future 
hostile  scenarios,  the  requirement  for  the  pilot  of  the  single  seat 
aircraft  to  maximise  his  situational  awareness  at  all  times  is  one  of  the 
prime  issues  in  driving  the  development  of  such  systems. 

This  paper  outlines  the  requirement  for  the  MMA  and  introduces  the  major 
functional  areas  of  sensor  fusion,  situation  assessment,  dynamic  planning 
and  the  Man-Machine  Interface.  The  paper  also  discusses  some  of  the  Human 
Factors  issues  associated  with  the  introduction  of  an  intelligent  Mission 
Management  Aid  (MMA)  and  the  increasing  need  to  promote  situational 
awareness.  Issues  relating  to  the  design  requirements  and  evaluation  of 
such  systems  are  also  discussed. 


1.  INTRODUCTION 


It  is  undoubtedly  true  that  the  operational  requirements  for  future 
military  aviation,  and  especially  the  future  single  seat  fighter,  are 
becoming  progressively  more  demanding.  Traditional  roles  are  being  extendo 
and  the  scenario  in  which  aircraft  will  be  required  to  operate  is  likely  to 
be  characterised  by  increasingly  hostile  and  capable  threats.  In  addition 
changes  in  the  perceived  threat  to  NATO  are  likely  to  result  in  an  emphasis 
on  a  rapid  response  to  threats  developing  outside  the  region  which  has  been 
the  core  of  NATO’s  thinking  for  forty  years.  In  an  effort  to  meet  these 
requirements  avionics  systems  are  becoming  increasingly  sophisticated  and 
integrated  and  the  pilot  is  required  to  manage  these  more  capable  systems 
in  an  increasingly  difficult  and  unpredictable  scenario  (Powell  &  Adams, 
1986)  . 


In  contrast  to  these  requirements  we  seem  to  hear  more  and  more  about  the 
failures  of  sophisticated  and  highly  integrated  systems  not  so  much  because 
the  system  fails  to  function  but  because  it  does  not  produce  the 
performance  expected  of  it.  The  pilot  is  often  cited  as  a  major  or 
contributory  factor  in  the  failure. 

In  reality  this  may  be  as  much  a  reflection  of  the  design  process  as  an 
indictment  of  either  human  or  operational  aspects  and  it  is  in  this  sense 
that  the  requirement  for  ’situational  awareness'  is  a  fundamental  aspect  of 
system  design.  Unless  the  designer  can  identify  the  requirements  of  the 
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pilot,  it  is  difficult  to  define  the  detailed  functional  specifications  for 
a  device  such  as  the  MMA.  This  problem  is  exacerbated  in  the  initial 
stages  of  system  conception  by  the  difficulty  in  obtaining  coherent  and 
consistent  views  from  pilots  in  response  to  fairly  open  questions  about  the 
operations  of  future  systems. 

We  may  define  situational  awareness  as  the  pilot’s  overall  appreciation  of 
his  current  ’world’.  This  implies  both  sensory  processing  and  inferencing 
on  the  part  of  the  pilot.  An  awareness  of  his  own  state  as  well  as  the 
state  of  his  aircraft  systems,  stores  etc,  and  the  current  mission 
situation  are  all  components  which  contribute  to  his  overall  situational 
awareness.  An  implication  of  this  is  that  it  is  difficult  to  measure  as  a 
global  metric  and  is  limited  in  its  utility  as  a  tool  to  predict 
performance.  Indeed,  this  ties  in  with  reality.  It  is  difficult,  even  for 
the  pilot  himself,  to  predict  situations  which  will  result  in  a  loss  or 
partial  loss  of  situational  awareness.  A  number  of  factors  such  as  an 
individual  pilot's  susceptibility  to  various  stressing  tasks/ incidents ,  his 
physiological  state,  current  level  of  training  etc.  will  all  affect  the  way 
in  which  he  allocates  his  attention  and  the  amount  of  resource  that  a 
pirt : i ular  situation  demands.  This,  in  turn  affects  the  speed  and  accuracy 
with  which  he  perceives  the  word. 

Nevertheless ,  pilots  put  increasing  importance  on  their  ability  to  maintain 
an  overall  situational  awareness  and  there  is  an  idoubted  requirement  to 
understand  what  factors  contribute  to  this  state,  to  identify  their 
relative  importance  and  thus  to  ensure  that  the  system  enhances  the  pilot’s 
situational  awareness  at  any  instant  in  time.  This,  in  turn,  reflects  on 
the  design  process 

There  is  a  fundamental  need  to  understand  what  information  (as  opposed  to 
data')  the  pilot  reeds  in  a  particular  mission  context,  how  that 
intimation  is  pe  sived  and  how  it  contributes  to  his  overall  situational 

awat  '’ness  . 

2  MMA  APPLICATION 

The  recall  objective  of  the  prototyping  phase  is  to  demonstrate  the  major 
:  n  -t  tens  of  the  KhA  in  an  integrated  form.  A  top  level  view  of  the  MMA  is 

;  '••••  :  :r>  figure  2. 


t;  side  rat  ion  of  a  number  of  possible  missions  and  scenarios  it  was 
do  Ltd  -hat  to  most  fully  exercise  the  MMA’s  functionality  the  initial 
proto*,  ype  should  operate  in  an  Air  to  Ground  role  although  the  capability 
to  caity  cut  air-to-air-missions  will  be  incorporated  in  a  later  phase. 
Within  the  air-to-ground  scenario  the  MMA  will  carry  out  several  missions 
within  the  current  NATO  structure  and  demonstrate  its  ability  to  respond  to 
intelligent  hostile  threats.  These  are  primarily  OCA/CAA  (offensive, 
counter -a ir /counter  air  attack)  and  AI  (air  interdiction)  missions. 


They  are  ideally  carried  out  by  a  small  group  of  aircraft  and  are  similar 
in  that,  they  are  principally  stealthy  missions  demanding  minimal  uxse  of 
active  sensors,  co-operation  between  aircraft,  and  a  high  decree  of  pre¬ 
planning  of  all  mission  phases  to  and  from  the  target.  The  importance  of 
group  opt  stions  in  future  scenarios  is  unquestionable  and  an  important 
aspect  of  the  MMA’s  operation  will  be  to  interact  with  other  MMAs  to  allow 
intelligent  target  hand-off,  attack  sequencing  and  communal  planning  of 
■  e  sour  :e  depl  yment . 


scenarios  are  based  on  a  100  x  ?00 
-si  Region  and  it  is  intended  that 
: * y  to  produce  a  single  view  of  the  outside  world 
s  mission  plan(s)  which  is  capable  of  inspection. 

1  ""in : t rate  the  ability  to  ’repair’  the  plan  as 
r  i'-n  '.iodateS  or  unforeseen  eve*ts. 


km  area  located  in  the  European 
the  MMA  should  demonstrate  the 

torough  its  sensors 
In  addition,  the  MMA 
function  of 


i  r. 
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3. 


FUTURE  SYSTEM  REQUIREMENTS  AND  THE  MMA 


System  design  and  development  often  follows  a  top  down  approach  (Meister, 
1976;  de  Neufville  &  Stafford,  1971).  From  initial  concept,  therefore,  the 
design  and  development  process  generally  proceeds  as  in  figure  3. 

In  practice  this  is  typically  an  iterative  process  where  evaluation  may 
result  in  a  revisiting  of  any  of  the  stages  above  it  (as  illustrated  in 
figure  3)  -  even  to  the  extent  that  it  may  sometimes  modify  the  objectives! 

It  is  also  evident  (Rouse  &  Cody,  1988)  that  this  is  not  a  completely 
tenable  approach  since  the  implied  dependency  of  each  stage  on  its 
predecessor  may  be  only  partially  true.  It  is  difficult  to  predict  the 
effect  on  performance  of  allocating  pilot  authority  to  specific 
tasks / functions  without  an  understanding  of  the  pilot  information  and 
control  requirements. 

This,  in  turn,  may  require  significant  evaluation  or  research.  The 
inadequacies  of  a  Top  Down  (or  Bottom  Up)  approach  are  largely  caused  by 
the  need  for  a  ’man-in-the-loop’  system.  Thus  a  flexible  mixture  of 
approaches  is  required  with  a  significantly  greater  emphasis  on  the  Human 
Factors  aspects  of  the  system  early  in  the  design  process.  This  should 
result  in  a  product  which  has  a  greater  prospect  of  satisfying  the 
customer’s  needs  and  also  minimises  the  iterative  design/ redesign  process. 
This  approach  is  reflected  in  the  MMA  design  process. 

4 .  MMA  CORE  FUNCTIONS 

Recognition  of  the  need  for  a  more  pilot-orientated  approach  has  been 
embodied  in  the  MMA  in  that  the  Man-Machine  Interface  (MMI)  development  has 
been  identified  as  a  separate  activity  which  can  proceed  in  parallel  with 
the  prototyping  of  the  major  functions.  Thus  the  human  factors  design 
considerations  are  seen  as  important  drivers  in  the  design  of  the  MMA 
itself  rather  than  vice-versa.  Consideration  of  the  MMI  and  information 
display  requirements  have  included  examination  of  fundamental  human  factors 
aspects  such  as  the  pilot  need  and  benefits  of  processed  sensor 
information;  potential  problems  associated  with  knowledge  databases  of 
tactics  and  assessed  threat  values;  the  display  of  optional  plans  including 
advice  on  tactical  routeing,  the  use  of  resources  etc. 

This  approach  has  led  to  the  production  of  a  series  of  Human  Factors 
guidelines  for  the  MMA  (Brydon  &  Stanger,  1986)  and  to  the  derivation  of 
the  four  major  functional  areas,  as  illustrated  in  figure  4,  viz:  Sensor 
Fusion,  Situation  Assessment,  Dynamic  Planning,  Man-Machine  Interface. 

These  core  functions  of  the  MMA  provide  a  tactical  plan  to  the  pilot,  which 
he  may,  wholly  or  partially,  accept  or  reject.  This  tactical  plan  is 
designed  to  satisfy  the  mission  objectives.  It  addresses  every  aspect  of 
the  mission  and  is  visible  to  the  pilot  through  his  cockpit  display  suite. 
Alternative  (and  presumably  less  favourable)  plans  are  produced,  and 
displayed  at  the  pilot’s  request.  There  are  four  main  processes  involved. 
Sensor  fusion  takes  data  from  a  number  of  sources  including  the  on-board 
tactical  database  and  combines  it  to  produces  a  single  fused  view  of  the 
outside  world  -  the  Alpha  scene.  This  is  combined  with  intelligence  data 
from  the  pre-mission  brief  database  to  produce  an  assessed  view  of  the 
situation  -  the  Beta  scene,  taking  account  of  the  objectives  of  the  current 
and  future  mission  phases.  This  assessed  view  and  the  overall  mission 
objectives  are  used  to  produce  a  number  of  tactical  options  -  the  plans  (or 
gammas).  Finally,  the  MMI  function  prioritises  the  information  presented 
to  the  pilot  and  manages  the  displays  and  multi -function  controls. 

The  core  areas  of  the  MMI  which  have  been  prototyped  to  date  are 
illustrated  on  figure  5. 

The  organisation  of  the  computer  equipment  used  to  prototype  the  MMA  is 
illustrated  in  figure  6.  The  Symbolics  Work  Stations  are  used  to  develop 
and  host  the  MMA  core  functions  whilst  the  Silicon  Graphics  are  used  for 
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the  Man  Machine  Interface.  The  Meiko  Computing  Surface,  a  transputer  based 
machine  hosted  on  a  Sun,  is  used  for  the  development  of  real  time  software 
for  the  full  scale  Mission  Capable  Simulation  of  the  MMA. 

4.1.  SENSOR  FUSION 

The  sensor  fusion  is  provided  with  data  from  the  aircraft  sensor  systems, 
communications  systems,  and  the  tactical  database.  This  information  is 
processed  in  two  stages  to  produce  an  alpha  scene,  which  is  the  view  of 
what  the  aircraft  can  see  in  the  outside  world,  together  with  associated 
confidence  intervals.  The  two  stages  in  the  sensor  fusion  process  are 
sensor  report  and  track  correlation  and  object  attribute  fusion. 

42.  SITUATION  ASSESSMENT 

The  Alpha  scene  is  passed  to  the  Situation  Assessment  function  to  produce  a 
Beta  scene,  which  contains  a  threat-prioritised  list  of  objects.  This  is  a 
multi-stage  process  in  which  firstly  the  known  friendly  objects  are 
filtered  for  separate  processing. 

The  remaining  hostile  and  unknown  objects  are  evaluated  for  threat  and 
target  potential. 

It  is  apparent  that  the  pilot  will  need  an  overall  view  of  the  assessed 
scene  whereas  the  subsequent  functions  will  require  a  more  detailed  view  of 
specific  parts  of  the  scene. 

4.3.  DYNAMIC  PLANNING 

This  is  the  heart  of  the  MMA  planning  which  constructs  tactical  plans 
(Gammas)  including  a  Gamma*  option  (the  most  favourable  gamma).  The  plans 
are  built  from  the  Beta  scene  input,  which  provides  the  planner  with  the 
"current  situation"  and  from  the  mission  objectives  provided  by  the  pre- 
mission  brief.  The  final  Gamma*  produced  contains  much  more  than  just  a 
proposed  route,  for  example,  the  proposed  employment  of  weapon  and 
countermeasure  systems,  and  a  3-dimensional  tactical  route  generated  by  the 
threat  avoidance  function,  which  are  fed  to  the  appropriate  aircraft 
systems . 

The  Planner  evaluates  options  for  an  Attack-Defence  strategy.  These 
options  take  account  of  the  mission  objectives,  potential  target  and  threat 
values  and  the  current  status  of  the  aircraft’s  weapons  and 

countermeasures . 

Small  scale  tactical  re-routeing  in  the  air,  for  threat  and  terrain 
avoidance  is  incorporated  at  a  low  level  in  the  Gamma(s).  The  output  is  in 
the  form  of  a  list  of  threat-avoiding  waypoints  for  utilisation  by  the 

navigation  system. 

4.4.  MAN-MACHINE  INTERFACE 

The  man  machine  interface  for  the  MMA  is  centred  around  the  Pilot  Interface 
Manager  (PIM).  The  PIM  may  be  considered  as  a  number  of  functions  which 
"organise"  the  information  required  to  be  presented  to  the  pilot  at  any 
time . 

The  core  functions  of  the  MMA  will  provide  information  relating  to  the 
current  situation,  proposed  MMA  actions/solutions,  status  of  systems  and 
cues  to  the  pilot,  and  the  PIM  will  prioritise  this  information  according 
to  the  pilot's  current  objective.  The  information  required  for  display  is 
scheduled  according  to  the  pilot’s  current  tasking,  which  will  be  monitored 
by  the  MMA. 

Another  important  aspect  of  the  MMI ,  will  be  in  ensuring  that  apart  from 
the  level  of  information  displayed  automatically  to  the  pilot,  he  can 
easily  and  naturally  access  lower  levels  of  information  to  explain,  or 
qualify  MMA  advice/plans  etc.  This  will  be  particularly  important  in  the 
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evaluation  of  the  MMA,  and  in  pilot  training  in  order  to  boost  confidence 
and  acceptability  of  the  system. 

5.  THE  RELATIONSHIP  BETWEEN  THE  MMA  AND  THE  PILOT 

A  team  of  fifteen  have  been  working  on  the  MMA  over  the  last  three  years. 

Of  this  number  three  have  a  significant  human  factors  background  and  one 
has  had  some  thousands  of  hours  fast  jet  experience  as  a  pilot. 

Early  work  on  the  Man  Machine  Interface  convinced  the  team  that  knowledge 
elicitation  from  experts  was  a  very  difficult  task  unless  the  experts  were 
asked  well  defined  questions.  It  was  determined  that  the  best  way  to 
define  the  questions  was  to  prototype  the  pilot  interface  and  its  displays 
and  controls  so  that  aircrew  could  be  asked  to  choose  between  alternative 
approaches  early  in  the  programme.  The  organisation  of  the  Work  Station 
Equipment  used  in  prototyping  is  shown  in  figure  5.  The  results  of  these 
researches  will  be  developed  in  the  real  time  mission  capable  simulation  of 
the  MMA  and  this  will  enable  more  exacting  evaluation  of  the  pilot 
interface  with  operational  aircrew.  This  environment  will  allow 
investigation  of  situational  awareness  in  high  workload  phases  of  missions. 

Refinement  of  the  distribution  of  function  between  the  pilot  and  the  MMA  is 
a  primary  purpose  for  this  development  and  evaluation  work  and  the  pilot’s 
capabilities  versus  those  of  the  machine  are  fundamental  to  this 
distribution. 

The  overall  task  has  three  levels  which  may  be  described  as  based  upon: 

a.  Skills 

b.  Knowledge 

c.  Inference 


A  postulate  for  the  division  of  function  for  these  three  levels  might  be  as 
follows : 

a.  Skills  -  Give  the  machine  the  routine  and  allow  the  man  the  time 
for  the  highly  skilled  tasks. 

b.  Knowledge  -  Include  a  wide  ranging  knowledge  base  in  the  machine 
and  provide  the  man  with  an  intelligent,  context  dependent  access  to 
this  knowledge  so  that  he  can  quickly  access  relevant  information. 

c.  Inference  -  Provide  inference  capability  in  the  machine  but 
organise  the  MMI  so  that  the  man’s  inherent  capability  for  inference 
can  complement  the  mechanistic  process  used  by  the  machine. 

Patently  these  postulates  are  imprecise  and  require  to  be  developed  in 
detail  during  the  simulation  and  evaluation  of  the  MMA. 

6.  CONCLUSIONS 

Situational  Awareness  is  the  key  to  the  improvement  of  mission 
effectiveness  in  future  combat  aircraft.  Enhanced  levels  of  intelligent 
automation  of  the  mission  avionics  of  these  aircraft  raise  the  possibility 
of  improved  situation  awareness.  This  improvement  will  not  be  achieved 
unless  the  balance  between  the  capabilities  and  needs  of  the  pilot  are 
carefully  balanced  against  the  potential  capabilities  of  the  enhanced 
mission  systems  at  every  stage  of  the  development. 

It  is  particularly  important  that  thi3  balance  is  established  at  the 
earliest  stages  of  the  development  of  systems  such  as  the  MMA  and  is  a 
primary  area  of  concern  at  each  major  review  evaluation  and  experimental 
trial  thereafter. 
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TYPICAL  DESIGN  PROCESS 


Figure  3 
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ABSTRACT 

Because  of  the  battle  field  complexity  pilots  will  face  Milical  situations.  They  need 
assistance.  However,  for  complox  situations  no  fully  proved  •mlulions  are  computable. 

Therefore,  decisions  have  to  be  elaborated  in  n  roopoiallvo  process  combining  the 
system  viewpoint  with  the  pilot  Intuition.  The  system  has  to  he  aware  of  the  pilot's  intent,  as 
well  as  the  pilot  needs  a  coherent  understanding  of  the  system  masoning. 

This  man-machine  coupling  perspective  constrains  tin*  Electronic  Copilot  architecture 
(such  as  type  and  presentation  output  results,  typo  and  nature  of  reasoning)  but  also  allows  to 
reduce  the  classical  burden  of  embedded  software  (stu  b  security  constraints,  decision 
optimality). 

As  a  result  of  these  advantages  ami  limitations,  the  nmn  machine  coupled  archllecluie 
Is  the  solution  for  successful  Electronic  <  opllol  DAKS  AIM  T-AVIATION  and  CERMA  are 
currently  working  on  this  line. 

INTRODUCTION 

In  order  to  maximize  the  mission  effbioncy  and  llm  f  »'••!  effectiveness  of  future  fighter 
aircraft  operations.  II  is  desirable  lo  plan  for  a  good  mnnngmmml  of  the  limited  and  valuable 
crew  time.  This  requires  a  good  allocation  ol  functions  bc'won  the  crew  and  automatic 
systems,  and  an  effective  Man-Machine  Intoilnce  (MMI1  desinu 

Automatic  systems  should  eventually  significantly  iedu«e  the  pilot  workload.  They  are 
even  necessary  for  actions  that  require  fast  and  highly  err  male  responses,  fastidious  and 
repetitive  tasks.  However,  humans  should  be  kept  in  the  loop  when  the  actions  require 
judgment,  multi-sensory  information,  correlation  of  data.  This  makes  humans  irreplaceable  for 
unplanned  and  contingency  tasks,  and  for  complex  critical  operations  that  require  supervision 

For  example,  pilots  in  combat  should  h«  relieved  ol  routine  monitoring  tasks  and  system 
operations  to  devote  more  time  to  tactical  operations  and  hiuh  level  actions.  They  would  then 
become  true  "managers". 

With  an  effective  overall  MMI  design,  l-'nefils  can  he  o^pre  led  in  the  following  areas: 

•  Systems  management 

•  Tactics  management 

•  Mission  management 

This  MMI  perspective  for  future  avionic  systems  in  c  ombnt  aircraft  design  is  now  possi¬ 
ble  with  the  emergence  of  Artificial  Intetlinenre  (At)  techniques  A  complete  Integration  ot 
these  technologies,  in  an  overall  MMI  do«dqn  Is  noressmy  to  piovide  the  best  operational 
capabilities.  The  application  of  this  Inloqmlod  design  piimiptes  is  well  Illustrated  by  the 
concept  of  the  Electronic  Copilot  for  future  smart  cockpit 

Slatting  with  a  slate  of  Iho  art  of  ten. 'in  experience  in  the  MMI  domain  by  CERMA.  a 
goneral  presentallon  of  DASSAULT  projerl  >>!  Ihe  Electronic  copilot  shows  the  Importance  ol 
the  Man  Machine  coupling  perspective  relate -e  lo  the  system  mm  hlleclure. 


BEST 

AVAILABLE  COPT 


143 


CE  DOCUMENT  EST  LA  *5ROPRlE  TE  D6  LA  SOCiETE  DASSAULT  AVIATION  M.  NE  PEUT  ETRE  UTILISE.  REPRODUlT  OU  COMMUNIQUE  SANS  SON  AUTORISATION  PROPRIETARY  OATA 


DASSAULT  I  I  [ 

AVIATION 


COGNITIVE  ERGONOMICS  AND  THE  DESIGN  OF  AN 
ELECTRONIC  COPILOT 


Human  factors  evidences  from  the  aviation  history  and  (he  literature 

When  a  computer  system  is  always  able  to  select  iim  host  solution  for  a  prohlem. 
current  aviation  policy  is  to  couple  this  aid  directly  to  the  plane  and  keep  the  pilot  out  of  the 
loop  The  picture  changes  considerably  wh-n  men  me  coupled  io  imperfect  aids  this  is  the 
present  (and  most  likely  future)  case  for  At  systems  applied  to  tactical  real  time  analysis 
Here  solutions  need  to  be  proposed  rather  than  executed  and  the  pilot  s  ability  to  judge  them 
must  be  maintained.  The  pilot  also  needs  to  he  in  Mm  i<«»e  '>t  reasoning  to  avoid  "magic" 
behavior  that  can  arise  from  blind  belief  in  Ihe  aid 

Recent  studies  on  human-decision  mippoit  system  <  onpling  all  point  to  a  general 
principle  of  coupling  that  has  obvious  hearing  on  these  solutions:  the  less  the  operator 
experience  has.  the  more  interactions  he  "  ill  have  with  Mm  -ystom.  Similarly,  the  less  the 
pilot's  experience,  the  pooler  the  quality  <1  his  intei nr  lions  "<ith  decision  support  systems 
with  optimal  reasoning  (Roth,  Bennett  and  Woods.  ff?87)  I  <-lu mi  (198 7)  frames  fhis  principle 
in  similar  terms  the  greater  the  user  naiveimss  as  rogaid'-.  >  support  system,  the  greater  the 
required  commonality  of  knowledge  and  •  masoning  ben-e-t.  system  and  user  (glass  box 
necessity) 

However,  the  glass  box  concept  can  be  applied  to  dillei.  nl  levels  o(  requirements 
-the  basic  level  consists  in  displaying  informations  m  a  natural  way  for  the  operator 
Natural”  means  quick  understanding  and  msource  free  lot  Mm  user  This  level  perfectly  fits 
the  concept  of  "Representation  aids’  as  proposed  in  the  Zmhaty's  taxonomy  Example  are 
now  numerous  in  the  technical  domains,  o  q  modern  cockpits  whose  respect  this  principle 
are  termed  "glass  cockpits"  (Airbus  A320.  Boeing  7B7/7r>7) 

-Ihe  second  level  is  more  demanding  ft  consists  in  resperlmq  same  reasonings  than  Human 
when  elaborating  a  decision  Thus,  in  contrast  of  level  t  Itu-.  level  severaly  constrains  the 
type  of  decision  the  system  could  propose  Nevertheless  this  loslriclion  could  serve  heller 
the  final  user  (namely  the  novice  user)  in  dealing  with  111* *  modem  Ilian  any  else  optimal  cal¬ 
culations 

However,  it  is  clear  that  a  decision  ai<i  cannot  he  sim  U\  identical  to  Human  behaviour. 
This  could  not  take  sense  as  well  for  computer  reasons  as  lot  irspective  abilities  of  Human 
and  computers  (speed  of  calculations  )  Rather  than  imilaling  pilots  reasonings,  the  true 
challenge  for  successing  in  coupling  an  elo<  Ironic  copilot  to  minis  is  much  more  to  be  capa¬ 
ble  to  tune  system  solutions  according  to  Mm  users'  degme  m  qualification,  the  flight  context, 
and  possibly  other  Human  factors  dimen  tons  Tlnr:  lie  rnilware  architecture  of  Ihe 
electronic  copilot  becomes  largely  influent  >  d  by  the  ronnlc  ■  mqniiements  the  system  lias  to 
respect  Anyway,  this  challenge  cannot  he  i -ached  willmul  .<  podiminary  good  representation 
of  pilots  reasonings  and  cognitive  needs  this  is  the  mason  >-hy  Ihe  CERMA  and  DASSAULT 
AVIATION  have  developed  extended  field  studies  of  pilnis  tmmdrm  behaviours  before  defining 
system  architecture 

Results  from  field  studies 

The  studies  were  conducted  on  pilots  cognitive  m  ii''iiim  riming  high  speed-low  altitude 
penetration  missions  over  a  four  year  penod  The  mission  <  on-asts  in  flying  from  an  allied  air 
(nice  base,  towards  a  target  designated  m  advance  and  when  i eacbed  (alter  sometimes 
approximately  1/2  hour  (light)  treat  it  (reconnaissance  bombing)  The  tlighl  has  to  be  as  fast 
as  possible  and  as  low  as  possible  to  avoid  being  dolor  led  Tim  (light  back  to  the  base  is 
also  at  low  altitude  and  different  from  Hie  mgiess  Tim  d.  i  ni-d  results  are  presented  into 
Amalberli  &  nl  1383  1930 

On  ground  mission  preparation 
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Mission  preparation  is  a  necessary  prerequisite  to  mission  execution  All  the  pilots 
spent  more  time  in  preparation  (50  to  65  minutes)  than  m  execution  (45  to  60  minutes).  Thus 
special  attention  was  paid  to  the  cognitive  piocesses  involved  in  Ihis  stage 

The  differences  between  expert  pilots  and  novices  in  mission  preparation  are  mainly 
related  to  metaknowledge.  The  pilots  detun'd  their  trajectories  ns  a  function  of  their  internal 
competency  models  Pilots  with  greater  experience  can  define  smaller  navigation  points  and 
have  more  candidate  points  to  choose  from  Novice  pilots  have  a  good  representation  ol  the 
kind  of  navigation  point  they  can  reach  They  tend  to  look  (<n  large  points,  which  places  a 
number  of  severe  constraints  on  their  itineraries  and  gives  ihetn  higher  overall  nautical 
mileage  than  expert  itineraries.  Beginnet  pilots  plan  lewm  way  points  than  experts,  in 
particular  between  entry  into  enemy  territo> v  and  the  target  (high  speed-low  altitude  condi¬ 
tions)  They  are  less  able  to  assess  relief  points  than  cxp'  iis  and  thus  plan  more  direct 
trajectories  calling  for  fewer  way-points 

This  analysis  of  flight  preparation  has  a  number  of  implir  ations  for  a  cognitive  model 
-when  a  pilot  takes  off,  a  large  set  of  potential  problems  have  ihondy  been  solved 
-pilot  strategies  elaborated  during  mission  preparation  mo  hilly  dependent  on  their  MK 
(internal  representation  of  competences)  Hie  flight  plan  is  d< 'signed  to  be  compatible  with 
the  pilot  know-how.  Thus  flight  plans  for  Hie  same  mission  order  can  differ  substantially 
between  experts  and  novices  (although  the  operational  ie-.nii  r  an  he  acceptable  in  both 
cases) 

Analysis  of  pilot  activities  during  flight 

It  is  clear  that  the  key  to  rapid  process  control  is  losomre  management  Because  of 
risks  and  the  high  dynamicity  of  the  process,  priority  is  given  lo  flight  control,  i  e  short  term 
activities.  Pilots  can  only  invest  in  medium  and  long  term  activities  -navigational  and  tactical 
anticipation-  when  the  flight  is  stabilized  for  a  sufficiently  long  period  of  time  with  correct 
parameters 

Inflight  activities  during  normal  operating  conditions  ran  thus  he  broken  into  three  categories 


(i) short  term  engine  and  navigation  handlinu 

Pilots  make  a  series  of  systematic  checks  ,al  the  stall  of  •<  it  leg  to  make  sure  they  have 
reached  the  required  parameters  (route,  speed  altitude) 

(ii) coherence  and  confidence  assessment 

The  risks  pilots  take  in  short  term  evolutions  when  Kiev  invest  in  long  term  activities  is 
closely  related  to  the  degree  of  fit  of  then  mental  model  of  the  situation  to  the  actual  one 
This  mental  model  can  lose  validity  because  of  inteifnro  i.mlls  ot  because  of  unexpected 
changes  in  the  environment  Pilots  are  twain  ot  these  n-  ks  but  cannot  invest  all  their 
resources  in  redoing  system  calculations  ot  doubling  !in>  n  in  a  sanation  They  thus  develop 
operative  strategies  to  enhance  confidence  m  their  shot  l  Imm  pi  relictions  with  minimal  risks 
so  lhat  then  can  devote  time  to  long  term  n<  hvilies  as  soon  .<•.  iiiey  consider  the  situation  will 
remain  stabilized  for  a  period  of  lime  These  strategies  nHv  on  logic  that  differs  considerably 
fiom  the  mathematical  and  physical  logic  ol  the  system  I  he  pitot  checks  that  the  situation  is 
coherent  with  low  altitude  flight  by  equaling  engine  lempei  iiuio  (in  degrees  Celsius)  with 
speed  (in  knots)  This  equation  is  purely  local  and  only  holds  lot  on-going  flight  conditions 
The  pilot  is  aware  of  Ihis  contingency  and  uses  the  observation  to  make  an  assessment  of 
system  normality  These  confidence  enhanr  oinenl  strategies  .no  applied  systematically  at  the 
end  of  a  series  of  short  term  actions  Since  these  are  reiniti  ated  every  20-30  seconds  they 
can  be  seen  as  prerequisites  for  allocating  iesourr.es  to  medium  and  long  term  reasoning 

Data  gathering  and  confidence  assessment  are  also  cp natty  facilitated  by  what  can  be 
termed  a  polysemiolic  trait  of  expert  knowledge  a  pilot  <  an  deduce  much  more  information 
fiom  one  dial  Ilian  the  flighlbook  indicates 

(ni)Navigational  and  tactical  anticipation 
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During  inflight  operations,  the  flight  plan  was  novel  ry.ni  ulml  as  defined  during  ground 
preparation.  Deviations  in  route,  timing  and/or  allilude  won'  observed  in  and  out  of  the 
context  of  the  incident  phase.  These  donations  occulted  systematically  (but  ranged  in 
magnitude)  between  the  takeoff  leg  and  entry  into  enemy  imnlnry  The  magnitude  of  the 
deviation  was  inversely  proportional  to  the  pilot's  exponent  e 

Protocol  analysis  and  interviews  indicate  that  iiovko  pilots  plan  a  detour  at  the 
beginning  of  the  flight  because  they  are  afraid  of  being  late  Im  lakeoff  (mission  preparation  is 
very  demanding).  Thus  if  they  are  late  thev  can  easolv  irrover  their  timing  by  taking  a  short 
cut.  This  points  out  the  crucial  importance  of  MK  in  the  icimintion  of  behavior,  as  we  saw 
earlier,  novice  pilots'  flight  plans  are  longer  because  of  llu-  nature  of  the  way  points  they 
select;  it  is  also  longer  because  young  pilol-  allow  Ihemsoivo*.  more  degrees  of  freedom  than 
expert  pilots 

Similar  strategies  were  observed  at  other  phase*;  in  llu*  mission  Some  pilots  believe 
that  they  will  be  detected  by  radar  because  of  the  conlevi  and  mnsider  that  the  best  solution 
is  to  accelerate  They  thus  decide  to  slow  down  at  some  « l i * •  i  mh  o  from  the  radar  in  order  to 
be  on  time  over  the  target 

When  considering  the  approach  to  the  target,  r.oinpaiison  between  novices  and  experts 
clearly  show  the  differences  in  terms  of  Ionic  of  reasoning  md  the  possible  handicap  due  to 
systems  guidance.  All  pilots  deviated  from  die  planned  mute  pist  before  the  target  because 
of  a  radar  threat  Then,  only  experts  recovered  the  planned  >  is  of  target  approach  Novives 
made  a  direct  trajectory  to  this  target  because  limy  lie  ■  Ihe  system  guidance  which 
permanently  indicate  the  direct  heading  to  target  without  i  n  hr  at  considerations.  Inversely, 
experts  had  to  ignore  the  system  informations  during  a  peiiod  of  10  to  30  seconds  in  order  to 
recover  the  planned  trajectory.  Thus  novices  attitudes  r  an  be  lenned  system  driven  although 
experts  attitudes  are  more  self  based  driven  In  llus  case  an  mlelligenf  assifance  in  guidance 
would  have  been  probably  profitable  to  novices 

Anyway,  it  results  from  these  studies  that  an  efertiom*  ropilof  would  largely  gain  in 
benefit  by  taking  into  account  the  cognitive  limitations  nt  llmmn,  namely  these  of  novices 
Another  pragmatic  consequence  of  these  studies  is  expertise  elicitation  which  directly  serves 
the  content  of  the  knowledge  base  of  Ihe  svslem  Because  *'l  tactical  complexity,  interviews 
ol  pilots  refering  to  concrete  missions  thev  have  rat  ivied  nut  ate  often  good  departure  for 
expertise  elicitations  giving  to  field  studio*;  a  multiple  inlet  o-t  in  (he  definition  of  the  future 
electronic  copilot 

THE  ELECTRONIC  COPILOT  CONCEPT 

Conducting  penetration  missions  in  hostile  temioiy  h  •  -  always  raised  problems  of 
workload  on  a  single  Pilot,  regardless  of  Hm  aim  all  r  milium  >hnn  These  problems  have 
generally  been  solved  by  applying  sliicl  mission  ronlml  ml.'  m  by  adding  a  second  crew 
member  However,  in  a  single  sealer  ainiall  oven  il  Hi*'  I  dol  is  relieved  of  routine  and 
repetitive  tasks,  mission  control  can  be  tin m  roptahly  romplt*  d*  d  Considering  that  Artificial 
Intelligence  could  provide  answeis  lo  tiles'1  emblems  nAftr.Ain  r  is  working  on  this  approach 
for  the  aircraft  of  the  2000-2010  decade 

Cognitive  aspects  of  the  Electronic  Copilot 

Man  in  the  loop  as  a  mission  manager 

Our  concept  is  clearly  putting  the  Pilot  m  the  loop  llm  t  loc.lronic  Copilot  will  only  pro¬ 
pose  decisions  lo  the  Pilol  or  present  inform  ltion  pertinent  foi  ihe  Pilot  decision  process  The 
Pilot  will  he  free  lo  accept  or  not  the  proposition  and  no  mtom.iiu  decision  will  be  taken 

This  implies  that  relevant  information  ■  bould  bo  m  m  in'  d  m  order  lo  minimise  Ihe  diver¬ 
gence  with  Hie  Pilol  line  of  reasoning  Foi  instance  a  p  ntn  id  <tly  important  point  in  Pilot  aid 
is  lilterinq  of  the  alarms  and  management  *d  omeii|enrv  pi*'*  -  dines  The  Pilot  must  he  able 
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to  supervise  control  of  the  various  aim  all  system*-.  m  ill  situations,  including  failure 
situations. 

Our  first  results  confirm  that  ttie  Elerhonic  Copilot  will  i nr  tease  the  importance  of  the 
man  machine  interface  as  it  will  generate  a  real  dialogue  with  the  Pilot  This  will  require 
Artificial  Intelligence  not  only  to  generate  displays  or  messages  luit  to  manage  the  pertinence 
of  information  depending  on  the  mission  phases  and  the  hisloiv  of  the  Pilot  activity.  It  will  be 
a  central  task  for  the  Electronic  Copilot  to  inter  continuously  Ihe  Pilot  activity,  and  to  exchange 
with  him  suitable  synthetic  information  in  older  to  assist  ihe  dm  i.ion  process 

Synthesis  of  diverse  classes  of  expertises 

The  Electronic  Copilot  will  address  •  <  very  large  lanqe  >>1  expertises  In  our  alarm 
filtering  development,  expertise  included  !!«•  knowledge  lelab  d  to  the  engines,  the  electrical 
generation,  the  hydraulical  generation,  ami  the  hrnkmg  system  A  dozen  of  experts  were 
involved  including  not  only  engineers  but  Pilots  and  eigoimms 

In  the  overall  Electronic  Copilot  expeitise  will  rover  m- >1  only  system  management  but 
also  tactical  reasoning,  strategic  mission  planning  and  man  machine  dialogue.  To  tackle 
these  difficulties  we  are  implementing  a  futt  mission  simulator  on  which  the  expertises  can  be 
globally  elicited  and  refined  using  on-line  interactive  snibmie 

This  situation  is  much  likely  to  be  the  < ommon  r  aw  in  l  hum  projects  of  Operator  assis¬ 
tance 

Constantly  evolving  expertise 

Most  of  (he  systems  we  design  today  wilt  ir-gnim  i  nowledge  that  has  not  been 
experienced  yet 

The  new  design  by  itself  can  modify  the  way  operalois  will  perform  the  task  or  even 
more  drastically  it  may  change  the  task  itself  Sometimes  problems  that  used  to  be  very 
difficult  to  solve  become  routine  and  other  reasoning  fields  regain  emphasis  For  example  in 
the  Electronic  Copilot  the  navigation  burden  of  Ihe  pilot  will  decrease,  leaving  more  time  to 
handle  complex  tactical  management 

In  combat  domain  the  dynamic  of  knowledge  evolution  is  even  greater.  Competition 
creates  the  need  for  constant  refinement  ami  creation  r>(  now  shalegies  For  example  in  mul¬ 
tiple  aircraft  engagement,  it  has  proven  net  essary  to  neat*'  <"-|V't|ise  without  collecting  rules 
from  human  experts  as  the  game  of  defence  vs  altar  ■*  in  •<<>-.  an  open  field  for  strategic 
behaviour 

This  constantly  evolving  expertise  is  oiion  ihe  me . h* Hm  assistance  concern  future 

projects  with  no  "real  life  experience 

Interface  constraints  (media  available) 

Crew  don’t  like  to  be  given  important  amount  of  data  they  only  wish  to  get  the  infor¬ 
mation  they  need  at  the  time  they  need  Tint  is  the  lenson  why  our  Company  is  working  for 
many  years  to  find  best  appropriate  ways  !*>  display  mini  malum  taking  in  consideration  that 

a  picture  is  still  worth  a  thousand  words  This  woik  has  1ml  us  lo  develop  in  fighters  head- 
up  flying  using  velocity  vector  and  energy  rale  for  all  tlu:  mission  phases  and  adding  very 
powerful  high  order  guidance  symbols  in  many  other  mode.  for  example  the  synthetic 
runway  with  associated  guidance  box 

We  are  now  thinking  that  At  technique--,  can  be  voiy  helplul  in  this  quest  for  best  interfa¬ 
ces  The  idea  is  to  continuously  adapt  the  display  contents  in  Ihe  situation  and  to  the  Pilot 
preoccupations  Moreover  Al  driven  corl  pds  are  fmeseen  is  natural  extensions  ol  our 
present  know-how 

The  importance  of  MMI  design  lias  led  our  Company  i*>  make  an  always  increasing  use 
of  simulation  techniques  Several  tools  an-  used  lo  *leim»»  Um  <  or  kpil  and  all  the  soflwaie- 
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driven  interfaces.  Final  assessments  and  adjustments  me  mule  with  an  important  partici¬ 
pation  of  flight-test  teams  in  our  simulation  facilily  named  OASIS  (for  Outil  d'Aide  a  la 
Specification  des  Interfaces  Systemes  i  n  Man-Machine  lut-if.ire  Design  Tool)  located  in 
Istres 

We  also  conduct  studies  concerning  on-board  use  of  voice  processing  and  its 
relationship  with  other  means  of  dialogue  displays,  keylmaul-.  dedicated  or  scd-keys 

The  Electronic  Copilot  project  is  now  tiyb.g  to  merge  om  I  nowledges  of  die  many  possi¬ 
ble  dialogue  means,  realistic  for  fighter  ncrnft  ol  of  Iht'  no-i  century  ^ome  direciions 
appear  as  very  promising  in  order  to  simplify  fiom  llm  Pilot  point  of  view  the  use  of  all  the 
aircraft  functions 

CONCLUSION 


•  Humans  will  still  be  heavily  and  dire*  tty  involved  m  Inline  missions  therefore  human 
factors  will  be  an  important  design  drlvm  for  new  system- 

•  Advanced  technologies  to  assist  humans  will  have  to  t-  integrated  early  in  the  design 
process 

Artificial  Intelligence  will  be  strongly  linked  in  the  Inline  with  Man  Machine  Interface 
design  This  seems  to  be  a  necessaiy  step  in  oidei  to  allow  efficient  management  of 
complex  missions  villi  man  in  the  loop 

The  Electronic  Copilot  concept  '"'ill  he  a  nnjoi  ’  mackthrough  for  modern  MMI 
design  of  futur  fighter  aircraft,  and  is  a  good  example  of  this  approach. 

The  project  is  now  moving  from  >  feasibility  study  In  an  exploratory  development 
phase  This  will  give  us  many  inlei -  sting  experienn's  about  the  proper  knowledge 
engineering  for  such  complex  MMI  dosum 
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Abstract  and  Introduction 

The  technology  to  insert  an  artificially  intelligent  decision  aiding  system  into  an 
aircraft  is  developing  rapidly.  The  existing  Pilot's  Associate  program,  a  cooperative  effort 
between  the  Defense  Advanced  Research  Projects  Agency  and  the  U.S.  Air  Force,  will  likely 
lead  to  an  advanced  development  program  and  flight  test  within  the  next  five  to  seven  years. 

This  paper  describes  the  state  of  the  technology  in  terms  of  its  mission  functionality,  and 
addresses  issues  that  will  impact  the  use  and  operational  acceptance  of  intelligent  systems.  The 
paper  also  discusses  the  potential  impact  of  the  technology  on  aircrew  training  and  selection, 
and  identifies  issues  regarding  the  integration  of  the  system  into  the  daily  mission  routine. 
Finally,  we  discuss  some  of  the  philosophy  and  psychology  of  the  relationship  between  the  pilot 
and  the  electronic  crewmember. 


Pilot's  Associate  History.  Successes,  and  Status 

The  Pilot's  Associate  (PA)  program  is  a  two  phase  effort  to  develop  a  single-seat  fighter 
pilot  decision  aiding  system  that  runs  in  a  real-time,  piloted  simulation  (Fig.  1).  Phase  One 
was  a  dual-award  contract  with  McDonnell  Aircraft  Company  and  Lockheed  Aeronautical 
Systems  Company  as  prime  contractors.  Specific  PA  descriptions  that  follow  were  derived  from 
the  Lockheed  system,  but  philosophies  and  issues  are  generic  in  nature. 

Phase  One  used  rapid  prototyping  development  with  major  demonstrations  of  the  PA 
system  at  the  midway,  Demonstration  2,  and  completion  points.  Demonstration  3.  The 
Demonstration  2  software  ran  on  general  purpose  symbolic  computers  in  about  six  times  real¬ 
time  and  showed  the  success  of  the  cooperating  knowledge-based  systems  approach  [1,  2],  The 
Demonstration  2  mission  was  realistic,  but,  being  a  narrow  mission  slice,  it  did  not  present  PA 
with  the  usual  range  of  mission  events.  Rather,  it  presented  a  subset  of  events  designed  to  show 
PA  breadth,  but  not  necessarily  depth. 
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Demonstration  3  employed  PA  in  a  more  complicated  mission,  with  deeper 
knowledge-bases,  and  still  had  performance  of  about  six  times  real-time.  It  again  used 
symbolic  processing  computers  and  a  medium  fidelity  cockpit  simulator.  A  front-end  Mission 
Support  Tool  allowed  pilots  to  set  parameters  and  defaults  in  determining  whether  the  pilot  or  PA 
would  perform  various  tasks  at  different  mission  stages.  This  tool  is  the  primary  means  for  a 
pilot  to  initialize  the  PA  for  a  particular  mission,  and  forms  the  baseline  for  pilot  expectations  of 
PA  behavior.  Since  expectations  and  predictability  are  keys  to  building  trust  [4],  the  Mission 
Support  Tool  provides  a  mechanism  for  establishing  the  associate  relationship  which  is  crucial 
to  pilot  understanding  of  the  PA. 

Phase  Two  began  in  early  1990,  and  will  culminate  at  Demonstration  4;  a  piloted,  full- 
mission,  real-time  demonstration  of  a  PA  with  similar  functionality  as  in  Demonstration  3. 
Demonstration  4  software  is  being  developed  in  C++  (a  structured,  object-oriented  programming 
language)  and  will  run  in  a  hardware  configuration  to  include  avionics  processors.  A  clear 
path  of  transition  to  the  Ada  programming  language  and  a  full  avionics  environment  will  be 
defined  at  the  conclusion  of  Phase  Two.  The  Demonstration  4  PA  will  be  tested  in  several 
fighter  aircraft  scenarios  to  quantify  the  operational  utility  of  a  pilot  decision  aiding  system. 

The  success  of  the  Phase  Two  effort  may  lead  the  Air  Force  to  fly  a  pilot  decision  aiding 
system  in  an  advanced  cockpit,  flight  test  demonstration.  Once  the  benefits  of  PA  are  measured 
and  validated,  decision  aiding  systems  of  this  type  may  be  adapted  to  cockpits,  crew  stations, 
and  missions  of  a  variety  of  aircraft  and  other  vehicles. 
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Figure  2:  Pilot's  Associate  Concept 


Functionality  and  Operational  I  Itilitv 

The  PA  was  broken  into  six  major  subsystems  roughly  approximating  fighter  mission 
responsibilities:  situation  assessment,  system  status,  mission  planning,  tactics  planning, 
pilot  vehicle  interface,  and  an  executive  coordinating  the  other  subsystems’  actions  (Fig  2). 

The  Pilot's  Associate  must  give  the  pilot  the  information  needed  to  accomplish  the  mission  - 
when  it  is  needed  and  in  a  manner  consistent  with  his  needs.  It  must  present  a  coherent  picture 
of  the  combat  situation  in  an  intuitive  format  on  a  display  medium  selected  to  help  him  focus  his 
attention  with  minimal  interference.  Further,  the  PA  must  not  impede  the  pilot's 
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innovativeness,  rather  it  must  free  the  pilot  from  mundane  tasks  allowing  innovative  ideas 
and  actions  to  develop  fully. 

In  essence,  the  Pilot’s  Associate  revolutionizes  the  cockpit  by  monitoring  pilot  actions 
and  adapting  its  activities  to  support  them,  rather  than  the  typical  automation  approach  that 
requires  the  human  to  monitor  the  machine's  performance,  sometimes  with  disastrous  results 
(31.  The  synergy  to  be  achieved  --  by  designing  for  the  computer  to  do  what  it  is  best  at;  by 
allowing  the  human  to  think,  evaluate,  act  and  innovate;  and,  by  encouraging  a  smooth  overlap 
of  responsibilities  based  on  the  human's  preferences  --  is  only  now  beginning  to  be  evaluated. 

While  experimental  validation  of  the  Pilot's  Associate  will  not  be  performed  until 
Demonstration  4,  some  preliminary  utility  studies  and  subjective  evaluations  already  indicate 
significant  potential  benefits.  Some  of  the  functions  most  promising  in  terms  of  operational 
utility  and  payoff  include:  assimilating  aircraft  systems  information  and  evaluating  the 
effects  of  failures  on  the  mission;  calculating  and  inferring  the  potential  mission  impact  of 
enemy  air  and  ground  threats;  coordination  and  communication  of  cooperative  tactics  between 
multiple  aircraft;  facilitation  of  quick  formation  rejoins  to  maintain  mutual  support  and  force 
integrity;  accurate  route  replanning  for  high-probability-of-success  contingency  plans; 
intuitive  information  presentation  for  quick  pilot  assimilation  and  enhanced  situational 
awareness;  and  adaptive  aiding  for  pilot/machine  task  management. 

User  Acceptance 

All  the  demonstrated  benefits  mean  nothing  if  pilots  ignore  or  shut  off  their  Pilot’s 
Associate.  A  sense  of  trust  must  develop  during  ground  training,  flight  training,  and 
operational  use,  if  the  PA  will  be  used  as  intended.  That  is  why  users  (pilots)  must  be  involved 
from  the  beginning  in  the  system  design  and  development.  The  program  managers,  engineers, 
and  developers  must  build  the  PA  to  be  flexible  enough  to  adapt  to  the  preferences  of  individual 
pilots,  just  as  human  backseaters  and  pilots  work  out  a  teaming  relationship,  known  as  crew 
coordination.  The  evolution  of  this  relationship  between  humans  does  not  happen  overnight. 

One  should  not  expect  more  from  intelligent  systems,  but  pilots  may  have  high  expectations. 
They  may  not  have  the  tolerance  for  error  that  they  do  for  fellow  humans,  even  if  they  have  a 
good  mental  model  of  how  their  PA  behaves  --  including  its  limitations  and  strengths. 

Preparing  for  PA  errors  and  graceful  degradation  may  mitigate  some  of  the  usual  human 
intolerance  of  machine  error  [41. 

Emergence  of  the  "Associate" 

Since  user  acceptance  is  crucial  to  Pilot's  Associate  success,  emphasis  on  the  teaming 
relationship  between  pilot  and  PA  is  warranted.  This  emphasis  is  manifested  in  the 
Operational  Task  Force  (OTF),  a  group  of  aviators  who  provide  a  link  to  the  end  users  and  who 
routinely  answer  PA  designers  questions  not  only  about  what  PA  should  do,  in  terms  of 
operationally  valuable  functions,  but  how  it  should  do  it  The  OTF  fosters  a  pilot's  trust  in  the 
system  by  influencing  PA  design  to  be  predictable  to,  and  compatible  with,  the  pilot  [5]. 

The  PA  designers  and  OTF  have  addressed  many  early  development  issues.  Some  of 
these  issues  are: 

1)  Using  the  concept  of  adaptive  aiding,  the  PA  will  assume  tasks  based  on  the 
pilot's  workload  and  pre-authorization.  This  implies  that  the  pilot  will  not 
necessarily  know  who  is  responsible  for  what  actions  at  any  particular  time.  Is 
this  potential  source  of  confusion  tolerable ? 

Current  crew  coordination  is  initially  based  upon  written  flight  manual 
instructions.  Details  usually  evolve  during  flights  when  the  crewmembers 
develop  an  unwritten  "contract"  that  determines  the  timing  of  actions  and 
individual  responsibilities.  The  Mission  Support  Tool  and  a  newer  concept, 
Principles  of  Interaction,  may  foster  the  development  of  teamwork  between  the 
pilot  and  PA  [61.  Real-time  testing  should  determine  our  success  in  fostering  the 
desired  level  of  teamwork  and  should  reveal  any  remaining  sources  of 
confusion. 
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2)  How  does  one  manage  the  tailorability  of  the  PA  in  a  standardization  context? 
May  each  pilot  set  display  preferences  and  tactics,  or  is  the  pilot  limited  to  a 
subset,  or  prohibited  from  tailoring  displays  and  tactics  entirely ? 

A  goal  is  to  allow  pilot  tailorability  in  the  belief  that  it  is  a  necessary  feature  for 
user  acceptance.  However,  it  is  more  likely  that  tailoring  will  be  done  at  the 
squadron  or  flight  level  rather  than  by  individual  pilots.  The  amount  and 
control  of  tailorability  is  an  open  issue,  though,  currently  determined  more  by 
program  schedule  and  cost  than  design  philosophy. 

3)  How  do  the  pilot  and  PA  grow  together ?  Does  the  pilot  really  need  to  develop  a 
relationship  with  the  PA  like  that  between  a  pilot  and  human  backseater? 

To  be  an  effective  combat  decision  aiding  system,  the  PA  must  be  robust  and 
flexible.  It  must  actively  support  the  pilot  in  all  flight  phases  and  throughout  the 
spectrum  of  fighter  aircraft  missions.  PA  must  work  synergistically  with  the 
pilot,  doing  tasks  for  which  it  is  best-suited,  and  freeing  the  pilot  to  concentrate  on 
pilotage  and  mission  success.  An  important  attribute  for  the  PA,  like  the  human, 
is  also  to  know  when  its  activities  are  inappropriate.  Pilots  often  tell  of  forcing 
an  inexperienced  or  less-than-capable  backseater  to  go  "cold  mike"  --  to  keep 
doing  the  job  but  to  keep  their  mouth  shut.  A  Pilot's  Associate  which  constantly 
needs  to  be  brought  up-to-date  by  the  pilot  during  or  after  mission  events  is  the 
antithesis  of  an  associate.  It  must  also  know  enough  to  be  quiet,  perhaps 
regardless  of  the  value  of  pilot-input  information,  if  the  interaction  could  detract 
from  the  pilot’s  attention  to  the  mission. 

We  cannot  over-emphasize  our  assertion  that  a  team  relationship  must  develop  between 
the  pilot  and  the  PA  for  mission  success.  The  Principles  of  Interaction  [6]  and  Mission  Support 
Tool  helps  build  the  requisite  teamwork  by  giving  the  pilot  a  window  into  the  PA  and  laying  the 
groundwork  for  the  crew  coordination  "contract"  mentioned  above. 

The  principles  assure  pilots  that  they  are  in  control  of  the  mission  --  that  the  machine 
supports  and  monitors  the  human,  not  the  reverse.  The  Principles  of  Interaction  define  the 
the  pilot-PA  relationship,  and  help  the  pilot  build  a  mental  model  of  how  PA 
example  principles  are: 

1)  The  pilot  is  in  charge. 

2)  Plans  may  be: 

Approved  or  rejected  explicitly,  with  little  effort; 

Approved  or  rejected  pre-mission; 

Approved  or  rejected  implicitly  by  pilot  action;  or, 

Ignored,  with  predictable  results. 

3)  The  effort  required  of  the  pilot  to  control  the  PA  must  be  less  than  the  effort 
saved  by  the  PA. 

4)  The  PA  must  operate  in  a  predictable  manner. 

5)  The  PA  is  required  to  monitor  the  pilot,  not  the  other  way  around. 

6)  The  PA  must  notify  the  pilot  of  key  (as  defined  and  set  by  the  pilot)  mission 
events. 

The  Mission  Support  Tool  enables  pilot  experimentation  with  different  adaptive  aiding 
schemes,  tactics  tailoring,  and  display  preferences.  This  tool  allows  the  pilot  to  exercise  a  priori 
control  over  PA  by  explicitly  establishing  some  details  of  the  crew  coordination  contract. 

Training  and  Pilot  Selection 

Having  addressed  the  pilot-PA  relationship,  what  is  the  potential  impact  on  pilots  of  these 
relationship  assumptions.  Questions  and  possible  answers  that  arise  are: 

1)  Will  PA  change  the  nature  of  the  individual  suited  to  be  a  pilot  ?  We  do  not 
believe  so.  In  fact,  by  allowing  the  pilot  to  concentrate  on  pilotage  and  weapons 
employment,  the  addition  of  the  associate  may  reinforce  the  value  of  the 
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traditional  qualities  commonly  associated  with  a  fighter  pilot.  A  guiding 
philosophy  is  to  have  the  machine  adapt  to,  and  work  for,  the  human,  not  vice 
versa. 

2)  Will  pilots  need  to  be  more  managers  than  warriors?  One  early  concept  of 
artificial  intelligence  in  aircraft  was  to  view  the  pilot  as  a  systems  manager  -- 
monitoring  and  approving/disapproving  recommendations.  This  philosophy 
has  been  reversed  entirely  in  the  Pilot's  Associate.  A  goal  is  to  reduce  human 
monitoring  and  managing  of  aircraft  systems  for  which  they  are  ill-suited  and 
poorly  motivated.  Rather,  by  developing  an  associate  to  support  the  pilot's 
strategic  and  tactical  skills,  he  will  regress  more  toward  the  warrior  state  than 
his  systems  management  tasks  allow  in  today's  aircraft. 

3)  How  important  will  training  become  to  acceptance  of  the  technology  and  for 
tuning  performance?  We  assert  that  training  will  be  crucial  because  training 
builds  trust.  Extensive  training  is  also  required  because  the  Pilot’s  Associate 
human-centered  design  philosophy  is  such  a  radical  change  from  the  traditional 
aircraft-centered  philosophy.  Ultimately,  less  training  should  be  required 
because  of  the  intuitive  and  intelligent  interface.  In  fact,  one  of  the  Principles  of 
Interaction  demands  that  pilot  control  of  PA  require  less  time  and  effort  than  PA 
saves  the  pilot  in  executing  the  mission. 

The  previous  discussion,  the  Mission  Support  Tool,  and  the  Principles  of  Interaction 
provide  a  framework  for  developing  a  successful  teaming  relationship  between  the  pilot  and  the 
Pilot' s  Associate.  One  logical  evolution,  however,  takes  the  argument  one  step  further,  and 
hinges  on  the  fact  that  Demonstrations  2  and  3  required  little  pilot  action  to  accomplish  difficult 
missions. 

Do  We  Need  the  Human  Pilot  at  all? 

A  fully-developed  Pilot's  Associate  would  likely  include  a  capability  to  take  over  the 
aircraft,  if  the  pilot  is  disabled,  and  do  more  than  simply  recover  to  straight-and-level  flight. 
Since  the  PA  conceivably  understands  the  situation  and  mission  context,  it  could  keep  the 
aircraft  safely  in  the  mission  pending  pilot  recovery.  This  capability  could  potentially  render 
the  PA  aircraft  autonomous. 

Does  this  obviate  the  need  for  some  or  even  all  pilots?  Possibly  in  some  aircraft  roles 
and  missions  but  not  generally.  The  guiding  philosophy  of  the  program  has  been  to  support  the 
cognitive  and  decision-making  abilities  of  the  human.  This  philosophy  evolved  out  of  the 
fundamental  recognition  that  computers  and  humans  are  each  better  at  specific  tasks, 
especially  when  supported  by  the  other.  There  are  also  technical  limiting  factors  such  as 
sensors  and  data  fusion/interpretation  algorithms  which  would  severely  affect  the  capabilities 
of  an  autonomous  system.  Another  scenario  is  perhaps  more  likely  -  a  cooperative  set  of  piloted 
and  semi-autonomous  platforms.  Whatever  the  eventual  application  of  the  technology,  it  is  only 
through  insightful,  educated  discussion  that  we  will  we  identify  critical  questions  and  answers 
before  the  Pilot's  Associate  and  related  systems  become  operational. 

Conclusion 

We  have  argued  strongly  for  research  into  the  psychology  of  the  associate  relationship 
between  humans  and  "intelligent"  computer  systems.  Unfortunately,  data  for  analyzing  such 
a  relationship  may  not  be  readily  available  until  such  systems  are  fielded.  Relationships 
analogous  to  what  we  expect  for  the  pilot  and  PA  should  be  studied  extensively  in  the  interim  to 
insure  functional  utility,  and  to  avoid  user  rejection.  Reliance  on  basic  principles,  such  as 
keeping  the  user  in  the  design  loop,  testing  and  training  extensively,  and  keeping  PA  as  robust 
and  flexible  to  individual  pilot  preferences  as  possible  can  only  help  build  the  required  trust  and 
teamwork  for  a  successful  mission. 
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EXPLAMATIOH  OP  WORISHOP  TEAM  ACTIVITIES 


(LAST  TWO  DAYS) 
TEAM  TASKS 


The  meeting  call  notice  identified  a  series  of  issues  relevant  to  human- 
electronic  crew  teamwork.  These  issues  set  the  focus  for  the  workshop  team 
discussions  conducted  during  the  final  two  days  of  the  meeting.  The  five 
guiding  issues  were  as  follows: 

1.  What  is  the  status  of  the  technology  needed  to  support  the  human- 
electronic  crew  teamwork  concept? 

2.  What  are  the  interface  issues? 

3.  What  technical  areas  should  receive  increased  emphasis  in  the  near 
future? 

4.  What  will  be  the  impact  on  pilot  selection  and  training? 

5.  How  far  are  pilot  aiding  concepts  likely  to  be  pursued,  i.e.  are  we 
moving  along  a  path  towards  replacement  of  the  human  pilot? 

In  addition,  specific  technical  issues,  which  had  arisen  repeatedly  during 
the  workshop  presentations,  were  identified  as  potential  topics  for  further 
detailed  discussion.  The  specific  technical  issues  were  as  follows: 
trust /confidence,  functional  description  standardisation,  representing 
uncertainty,  real  time  AI,  levels  of  autonomy,  dynamic  function  allocation, 
and  goal  tracking. 

In  order  to  enable  the  workshop  teams  to  address  these  issues  in  a  systematic 
manner,  an  outline  structure  was  proposed  for  the  discussion,  described  on 
the  form  overleaf.  The  two  key  factors  of  the  meeting  -  AI  and  the  cockpit  - 
were  identified  as  the  primary  topics.  Each  of  these  primary  topics  was 
further  divided  into  three  different  discussion  areas  -  state  of  knowledge, 
unresolved  issues,  and  potential  directions. 

The  workshop  participants  were  divided  into  five  multi-national  teams.  Each 
team  was  tasked  to  address  any  or  all  of  the  issues  raised  by  the  workshop, 
u  g  the  proposed  structured  framework  for  guidance  as  far  as  possible.  In 
tne  event,  after  a  series  of  lively  discussions,  each  team  came  up  with  an 
independent  set  of  conclusions,  structured  in  a  variety  of  ways,  representing 
the  diversity  and  richness  of  their  interactions.  The  team  chairs  presented 
their  conclusions  in  the  final  plenary  session  of  the  meeting,  and  prepared 
the  written  summaries  provided  in  the  following  section. 
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WORKSHOP  OBJECTIVE.  To  identify  the  state  of  knowledge,  unresolved 
issues  and  potential  directions  in  aircraft  applications  of  Al  technology 
and  the  impact  on  the  cockpit  of  the  Human-Electronic  Crew. 

FORM  AT  _QF_W  Q  R  KING  GROUP  ASSIGNMENTS 


AGENDA 

TOPIC  j 

Al  TECHNOLOGY 

COCKPIT  IMPLICATIONS 

1 .  STATE  OF  KNOWLEDGE 

Levels  of  understanding. 

Current  practice  methods 
and  techniques. 

1.1 

9 

• 

2.1 

9 

• 

2.  UNRESOLVED  ISSUES 

Areas  of  uncertainty. 

Research  and  development 
requirements. 

1.2 

9 

■ 

2.2 

9 

• 

3.  POTENTIAL  DIRECTIONS 

Alternatives.  Choices, 

Priorities 

Costs  /  benifits. 

1.3 

9 

• 

2.3 

9 

■ 

N.B.  All  groups  to  address  all  cells  in  the  order  indicated. 


SAMPLE  ISSUES 

( 1 )  What  is  the  current  state  of  the  art  needed  to  support  the  concept  of  the  Human/Electronic 
Crew? 

(2) What  technical  areas  should  receive  the  most  emphasis  in  the  immediate  future? 

(3) What  sort  of  schedule  for  operational  application  of  this  concept  are  the  experts  willing  to 
predict? 

(4)  How  far  will  the  concept  be  pursued  i.e.  are  we  moving  along  a  path  toward  replacement  of 
the  human  pilot? 

USEFUL  QUESTIONS 

PRIMARY  -  What?  Which?  Why? 

SECONDARY-  How?  Who?  Where?  When? 

POTENTIAL  REQUIREMENTS  AND  CQMSTBA1MTS 

PRIMARY  -  Operational  (Environmental) 

Technical  (Physical,  Computational) 

Psychological  (Social.  Emotional,  Moral) 

SECONDARY  -  Economical,  Political,  Physiological,  Biological,  Sociological,  Philosophical. 


WORKSHOP  TEAM  REPORTS 


TEAM  Mo  1 


We  began  our  discussion  by  taking  a  vote  of  interest  in  the  topics  that  had 
been  presented  for  consideration.  We  took  the  vote  merely  to  determine  the 
most  productive  starting  point  for  our  discussion  with  the  understanding  that 
the  discussion  would  be  free  to  roam  into  the  other  areas  as  it  might.  The 
topics  of  pilot  trust  in  an  EC,  dynamic  function  allocation,  and  levels  of 
autonomy  each  received  three  votes,  real  time  performance  received  two,  and 
representing  uncertainty  and  functional  standardization  each  received  one, 
from  the  subgroup  of  people  who  would  be  present  on  Friday.  Regarding  the  four 
questions  posed,  pilot  selection  and  training  received  five  votes,  interface 
issues  four,  and  whether  the  pilot  would  be  replaced  two.  Because  the 
subgroup  that  remained  on  Friday  was  composed  mostly  of  human  interface 
people,  we  decided  to  concentrate  on  cockpit  implications  and  generally  ignore 
the  Al  technology  issues,  feeling  that  we  would  have  little  to  contribute  to 
that  topic  and  that  concentrating  in  the  one  area  would  enable  us  to  go  a 
little  deeper  into  it  than  other  groups  might. 

Trust 


On  Friday,  we  opened  our  discussion  on  the  topic  of  trust.  The  point  was 
made  that  we  are  already  facing  issues  of  trust  (both  under-reliance  and 
over-reliance)  in  existing  automated  systems,  and  that  some  over-reliance 
problems  bring  up  training  issues.  In  order  for  the  pilot  to  know  when  to 
trust  the  automation,  he  needs  to  understand  the  system’s  modes  and  to 
recognise  when  its  safety  processes  are  or  are  not  operating  correctly.  We 
can  already  see  the  issues  cropping  up  in  the  use  of  the  "open  descent"  mode 
in  the  A320  and  autoland  in  the  757  and  767.  It  was  suggested  that  we  might 
learn  something  from  process  control  displays,  as  people  working  in  that  area 
have  had  to  devise  concise  representations  of  complex  system  states.  Clear 
system  status  displays  that  promote  better  understanding  of  the  system  state 
may  help  calibrate  reliance  on  the  system. 

It  was  suggested  that  a  set  of  metarules  for  automation  for  all  systems  might 
be  devised.  These  would  establish  rules  of  behaviour  that  apply  to  all 
highly  automated  systems.  A  uniform  treatment  of  automation,  with  standard 
constraints  on  its  behaviour,  would  do  much  to  promote  predictability. 

Another  factor  that  would  promote  predictability  is  a  standard,  transparent 
interface.  As  flexibility  increases,  the  potential  for  memory  loading  and 
confusion  also  increases.  This  makes  the  need  for  a  good  pilot-vehicle 
interface  design  all  the  more  imperative. 

It  was  also  suggested  that  continuous  confirmation  of  correct  operation  would 
promote  trust,  even  though  some  theorists  say  that  trust  only  develops  under 
conditions  of  risk.  Fly-by-wire  was  brought  up  as  an  example. 

FUNCTION  ALLOCATION 

With  regard  to  dynamic  function  allocation,  we  had  an  extensive  discussion  of 
the  need  for  pilot  confirmation  of  task  reallocations.  It  was  suggested  that 
single  seat  cockpits  were  developed  largely  because  of  the  potential  for 
confusion  about  and  usurpation  of  responsibilities.  It  was  also  suggested 
that  the  Associate  concept  doesn't  fit  within  the  military  command  structure, 
that  there  were  no  "associate" -like  relationships  in  the  command  hierarchy. 
This  point  was  disputed  during  the  presentation. 
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The  point  was  also  made  that  dynamic  function  allocation  is  a  large  step  from 
the  current  state  of  the  art.  Such  a  large  step  requires  a  carefully 
considered  approach.  One  participant  wondered  if  dynamic  functions  allocation 
occurred  between  human  crews,  and  another  responded  that  it  did  and  was  a 
necessary  attribute  of  the  job.  However,  the  point  was  also  made  that  there 
is  much  implicit  and  gestural  communication  between  human  crewmembers,  and 
that  "a  glance  is  a  high  bandwidth  channel”  not  available  between  a  human  and 
an  EC . 

Finally,  it  was  suggested  that  automation  is  currently  technology-driven 
rather  than  human  factors-driven,  and  that  a  great  need  exists  for  structured 
guidance  from  the  human  factors  community  on  how  automation  should  be  applied. 
However,  this  is  in  part  a  selling  job,  as  automation  developers  and 
implementers  may  not  be  aware  of  the  human  factors  issues  associated  with  it. 

V.A.R. 


TEAM  No  2 

We  started  by  identifying  a  number  of  issues  that  should  be  considered. 

These  issues  were  discussed  at  some  length  and  a  set  of  key  technical  issues 
were  defined.  These  topics  were  as  follows: 

a .  Trust /Confidence 

This  area  has  been  poorly  researched  and  is  an  area  that  will  need 
further  work  if  we  are  ever  to  achieve  the  full  benefit  of  the 
electronic  crew  member.  The  lack  of  research  effort  in  this  area  is  a 
major  concern. 

b .  Representation  of  Uncertainty 

Both  the  electronic  crew  member  and  the  pilot  will  make  ’soft’  errors. 
Thus  systems  must  be  designed  to  allow  for  the  facts  that  errors  will 
occur.  Therefore,  both  the  machine  and  human  must  monitor  for  errors. 

It  is  critical  that  systems  are  designed  to  be  robust  in  the  face  of 
errors  . 

In  terms  of  current  technology,  it  is  possible  to  represent  the  nature 
of  machine  and  human  error.  However,  there  needs  to  be  work  to  match 
the  two  sources  of  error  representation.  There  also  needs  to  be  work  on 
the  matching  of  error  levels  to  the  needs  of  the  task. 

The  final  question  is  to  define  a  relationship  between  the  high  level 
mission  objectives  and  the  error  levels  that  are  acceptable  for  the 
human  and  the  machine . 

c .  Goal  Tracking 

It  is  a  fundamental  aspect  of  the  concept  of  the  Pilot’s  Associate  (or 
Electronic  Crew  Member)  that  the  machine  component  has  some  view  of  the 
pilot’s  intention.  There  is  a  basis  of  theoretical  research  in  terms  of 
plan  recognition,  but  this  has  not  yet  been  applied  to  the  problems  of 
the  aircraft.  In  particular,  there  is  a  lack  of  understanding  of  how  to 
cope  with  the  multiple  goals  that  the  pilot  maintains. 
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d. 


Real  Time  AI 


Many  of  the  Issues  in  real  time  AI  applications  have  been  solved.  The 
major  need  is  to  achieve  good  applications  experience  to  develop  a  base 
for  the  development  of  systems.  The  major  area  of  endeavour  should  be 
the  development  design  methods. 

e .  Levels  of  Authority 

This  is  an  area  that  has  not  been  addressed  with  any  success  so  far. 

There  is  a  natural  concern  amongst  aircrew  that  they  will  not  be  in 
control.  However,  a  review  of  the  performance  and  functionality  that 
will  be  required  shows  that  we  cannot  expect  the  pilot  to  be  in  control 
in  all  circumstances.  This  is  an  area  that  needs  to  be  addressed  at  a 
policy  level  as  much  as  at  a  research  level. 

Function  Descript ion/ Standardisation 

The  workshop  included  a  paper  on  standardisation  for  the  pilot  interface. 

The  key  aspect  of  this  paper  was  the  development  of  an  agreed  approach  to  the 
description  of  functions  that  a  pilot  undertook.  This  is  in  contrast  to  the 
more  frequent  approach  to  standardisation  which  is  to  consider  the 
specification  of  symbology,  display  layout  and  control  placement. 

The  working  group  felt  that  this  approach  was  the  basis  for  solving  a 
fundamental  aspect  of  the  relationship  between  the  human  and  electronic  crew 
members.  Without  a  basis  for  description  of  functions,  it  is  impossible  to 
consider  how  roles  are  allocated,  on  both  a  static  and  dynamic  basis.  Until 
there  is  an  agreed  and  coherent  description  of  functions,  it  will  still  be  the 
case  that  the  electronic  crew  members  are  technology  led  rather  than 
satisfying  a  clear  service  need.  For  this  reason,  it  was  felt  that  this  topic 
should  be  singled  out  by  the  participants  of  the  meeting  as  the  area  into 
which  further  collective  effort  should  be  invested  to  ensure  that  appropriate 
attention  and  resources  are  allocated. 

Conclusion 


In  addition  to  directing  attention  of  the  conference  to  the  final  item  of  the 
technical  issues,  there  was  a  general  comment.  It  was  felt  that  there  was  a 
lack  of  continuity  between  the  two  conferences,  there  could  have  been  a  scene 
setting  session  at  the  beginning,  summarising  the  issues  raised  at  the 
previous  conference,  this  would  have  defined  a  basis  for  monitoring  progress 
and  identifying  trends  in  the  development  of  the  electronic  crew  member. 

Finally,  this  workshop  group  would  like  to  thank  the  organisers  of  the 
conference  for  a  stimulating  and  successful  meeting. 


J.C. 


TEAM  Ho  3 


The  viewgraphs  used  during  the  summing  up  by  the  session  chairman  utilised 
the  previous  workshop  format  for  summarising  the  issues  and  problems  to  the 
Workshop.  The  categories  encapsulated  by  the  matrix  sometimes  obscured  the 
salient  details  which  emerged  during  the  discussion  sessions  using  the 
evaluation  criteria  laid  down  by  the  Organising  Committee.  The  findings 
reported  and  views  expressed  were  generally  related  to  the  scale  of  activity 
undertaken  and  the  level  of  appreciation  of  relevant  disciplines  and  related 
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technologies  involved  in  producing  computer  based  advisors. 

Technology  Status  to  Support  Electronic  Crewmember  Concept 

Technology  development  has  been  uneven  with  large  advances  in  some  narrowly 
focused  software  areas  resulting  in  unfulfilled  potential  due  to  lack  of 
consideration  of  wider  integration  issues.  Individual  demonstrators  still  do 
not  approach  general  human  reasoning  capabilities  where  shortcomings  still 
are  evident  in  such  areas  as  conflict  resolution,  and  reasoning  in 
uncertainty  in  dynamic  environments  so  exposing  the  limitation  of  rule  based, 
Bayesian  reasoning.  Means  of  presentation  of  visual  information  and  verbal 
input/output  devices  are  being  developed  in  isolation  without  adequate 
consideration  of  integration  with  or  maximising  capabilities  of  the 
electronic  advisors  potential.  Sadly,  this  indicates  the  all  too  familiar 
experience  of  the  unsystematic  approach  typically  associated  with  the 
introduction  of  a  new  technology  when  Human  Factors  personnel  have  not  been 
involved  during  the  appropriate  phases. 

Interface  Issues 


Communications  and  interaction  between  the  Human  and  the  Electronic 
Crewmember  were  identified  as  the  crucial  interface  issues.  The  resultant 
and  often  experienced  mismatch  between  technology  potential  and 
demonstrators’  limitations  were  often  a  manifestation  of  the  insufficient 
attention  given  to  an  overall,  systematic  approach  discussed  under 
technology  status.  Conventional  textural  or  graphical  outputs  associated 
with  computer  systems  have  been  found  to  be  grossly  inadequate  in  conveying 
information  when  required  by  aircrew  and  massively  underscores  the 
information  technology  potential  of  the  electronic  aircrew  systems. 

Technical  Areas  Requiring  Increased  Emphasis 

A  more  systematic  approach  is  required  to  exploit  and  usefully  combine  the 
individually  demonstrable  potential  of  interface  media.  Voice  interaction 
technology  was  an  example  discussed  of  an  available  technology  which  ought  to 
be  effectively  combined  with  the  electronic  crewmember  to  produce  the  near 
symbiotic  relationship  which  is  often  found  between  effective  front  and  rear 
human  crewmembers.  Due  to  the  heuristic  nature  of  much  of  the  reasoning 
employed  together  with  the  exploitation  of  incomplete  data  then  more 
attention  needs  to  be  applied  to  developing  evaluation  techniques  and 
validation  procedures  to  cover  these  novel,  and  sometimes  unique  systems.  In 
step  with  the  need  for  the  development  of  specialised  validation  procedures, 
as  a  preliminary  to  airborne  certification,  the  requirement  for 
implementation  of  military  software  in  Ada  would  require  a  significant  effort 
in  incorporating  the  unique  software  structures  used  in  intelligent  systems. 

Impact  on  Pilot  Selection  and  Training 

The  exploitation  of  the  educative  effect  of  close  association  with 
intelligent  systems  technology  was  seen  as  a  positive  effect,  especially  when 
coupled  with  aptitude  tests  to  determine  computer  numeracy  during  selection. 
Intelligent  systems  were  seen  as  raising  the  competence  of  the  aircrew  and 
the  explanation  facilities  provided  feedback  of  performance  and  re-enforced 
Learning  during  training. 

Redundant  Aircrew? 


General  agreement  that  the  research  aim  was  not  to  replace  the  pilot  but  to 
make  him  more  effective  by  exploiting  the  technology  to  produce  an  electronic 
advisor  and  maximising  human-electronic  crewmember  capability. 


I  AO 


Advances  to  date  have  been  substantial  but  what  is  required  is  for 
researchers,  managers  and  requirements  specialists  to  be  less  parochial  in 
order  to  fully  realise  the  potential  of  the  technology  as  outlined  by  the 
Keynote  Speaker. 


H.H. 


TEAM  No  4 


Current  Status 


Question  1  What  is  the  status  of  the  technology  needed  to  support  this 
concept? 

This  was  addressed  in  the  following  ways: 

Artificial  Intelligence  and  Technology  (Fig  1) 

The  academic  and  scientific  community  are  now  more  confident  of  the 
ultimate  feasibility  of  implementation.  Various  software  and 
methodologies  have  been  established  and  evaluated  in  the 
laboratory. 

The  levels  of  understanding  of  the  enormity  of  the  task  are  now 
starting  to  filter  down  to  the  engineering  design  and  Duild 
community. 

The  academic  and  scientific  communities  confident  view  that  this 
is  now  merely  a  question  of  building  an  engineering  implementation 
of  their  concepts,  is  not  presently  shared  by  the  engineering 
community. 

Cockpit  Implementation 

The  academic  and  scientific  community  are  now  more  aware  of  the 
pilot’s  problems.  The  understanding  of  pilot  interaction  and  needs 
with  regard  to  the  AI  interface  has  been  greatly  improved  in  the 
last  2  years.  The  concept  of  a  scientific/engineering/pilot 
workshop/forum  such  as  this  conference  is  invaluable  and  should  be 
encouraged. 

The  status  of  the  various  sub-systems  making  up  a  Pilot  Associate 
program  was  evaluated  as  follow: 

System  Status  Expert  (Fig  2) 

The  most  simple  to  implement  in  terms  of  engineering  effort. 
Very  well  advanced.  No  problems  anticipated  in  terms  of  final 
implementation. 

Mission  Manager  Expert  (Fig  3) 

Moving  map  displays  and  navigation  systems  using  latest 
technology  together  with  extensive  digital  data  bases  such  as 
DMA  DTED  and  DFAD  are  presently  implemented. 
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Automatic  navigation  reversion  and  route  planning  is  very  well 
advanced  using  simple  AI  techniques  and  extensive  processing. 
No  problems  are  anticipated  in  following  through  this  work. 

Situation  Assessment  Expert  (Fig  4) 

Long  Range  Radar,  Forward  Looking  Infra  Red,  and  Millimetric 
Sensors  are  here  now.  Acoustic  sensors  are  presently  well 
advanced.  The  outstanding  issues  are  how  to  present  this 
plethora  of  sensor  data  to  the  pilot  in  a  readily  assimilated 
manner.  (The  so  called  "Sensor  Fusion”).  Automatic  Target 
Recognition  is  progressing  but  is  at  present  not  as  successful 
as  was  anticipated.  However,  this  problem  is  thought  to  be 
solvable  with  advances  in  technology. 

Tactical  Expert  (Fig  5) 

The  decision  maker  or  evaluator  of  the  total  situation  is 
presently  far  behind.  It  is  in  this  area  that  the 
academic / scientific  community  is  presenting  a  whole  series  of 
conflicting  opinions  which,  until  these  are  resolved,  the 
engineering  builders  will  not  progress.  What  are  the  rules? 
How  are  they  learnt7  How  are  decisions  communicated  to  the 
pilot?  Until  these  questions  are  answered  this  expert  will 
stay  unbuilt. 

Pilot  Executive  Expert  (Figs  6) 

This  sub-systen  which  was  originally  conceived  as  being  an 
overall  executive  manager  residing  between  the  individual 
system  experts.  This  expert  being  the  source  of  the  pilot/AI 
interface.  This  concept,  of  a  separate  executive  expert,  now 
seems  to  have  been  quietly  dropped. 

Question  2  What  are  the  Interface  issues?  (Fig  7) 

Interfacing  to  the  pilot  is  straightforward  in  low  workload 
situations.  In  high  workload  situations  the  pilot  is  so  busy 
he  may  overlook/ ignore  the  associate  unless  the  information  is 
timely,  relevant  and  clearly  presented.  The  former  should 
present  no  problem.  However,  thp  relevance  presents  more  of  a 
problem  in  a  complex  scencio  and  until  this  is  fully  defined 
it  is  difficult  to  envisage  the  precise  implementation  of 
presentation . 

Unresolved  Issues 

At  present  there  are  single  seat  aircraft  and  two  seat  aircraft.  Does  one 
gradually  increase  the  capability  ~f  the  single  seat  operator  by  means  of 
Pilot  Associate  techniques  until  in  the  final  analysis  one  has  an  effective 
2  seat  aircraft  or  does  one  gradually  replace  the  second  seater  in  a  two  seat 
aircraft  until  the  two  seater  becomes  a  single  seat? 

At  some  "’me  before  the  next  generation  of  one  or  two  seat  aircraft  are  laid 
down,  this  qestion  must  be  resolved.  One  cannot  have  a  one  and  a  half  seat 
aircraft . 

Pilot  feedback  suggests  that  in  addition  to  being  a  systems /mission  manager, 
the  rear  seat  operator  is  invaluable  as  an  additional  pair  of  eyes  in  close 
air-to-air  engagements.  History  suggests  that  this  situation  will  always  be 
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with  us,  despite  untold  predictions  that  long  range  standoff  weapons  will 
eliminate  this  threat.  In  this  case  the  requirment  exists  to  develop  a 
close  air-to-air  engagement  360°  solid  state  visual  sensor  with  the 
capability  of  identifying  and  reporting  any  necessary  immediate  evasive 
action  to  the  pilot,  e.g.  "break  right  now!" 

The  Future 


Question  1  How  far  will  the  Pilot  aiding  concepts  be  pursued? 

Is  it  thought  that  we  are  moving  along  a  path  towards 
replacement  of  the  human  pilot? 

It  is  not  expected  that  the  human  pilot  will  ever  be  replaced  in  the 
foreseeable  future  for  the  following  basic  reasons: 

1.  Flexibility  -  In  a  combat  scenario  the  basic  mission  can  be  planned 
to  the  last  detail.  However,  between  the  time  of  planning  and 
execution,  the  situation  can  change.  A  human  operator  can  assess  the 
now  situation  and  replan  and  re-execute  in  a  flexible  manner. 

2.  Trainability  -  A  human  is  capable  of  learning  without  being 
taught.  This  process  is  imperfectly  understood.  At  present  we  are 
still  struggling  on  the  concepts  of  the  best  methods  of  teaching  AI 
machines  and  establishing  that  they  have  learnt  correctly;  far  less 
enabling  or  even  allowing  them  to  learn  on  their  own  experiences. 

3.  Responsibility  -  At  present  the  pilot  is  responsible  for  the 
actions  of  his  machine.  Everyone  is  fully  aware  of  the  irksome  habits 
of,  initially,  banks,  shops,  airlines  (and  now  in  virtually  every 
sphere)  for  lax  or  poor  performance  to  be  laid  at  the  door  of  computer 
breakdown  or  error.  The  infamous  "Sorry  it’s  not  my /our  fault,  it’s  the 
computer " . 

Envisage  a  combat  or  war  scenario  with  an  unmanned  attack  aircraft  with 
full  artificial  intelligence  making  autonomous,  self  taught  weapon 
released  decisions.  Who  would  be  responsible? 

The  user  -  Squadron  Commander 

-  Airforce  Chiefs 

-  President 

The  manufacturers  -  Designer 
-  Tester 

"None  of  our  other  ones  has  done  this  before!  It  was  a  healthy,  well 
adjusted  intelligence  when  we  shipped  it  from  the  factory,  you  must 
have  taught  and  treated  it  badly  to  create  this  situation". 


M.L.B. 


Team  No  5 


AI  Technology 
1 .  State  of  Knowledge 

Hardware  developments  have  outstripped  software  progress. 
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Availability  of  rapid  prototyping  greatly  helps  the  exploration  of  new  ideas. 

Not  enough  time  is  spent  with  the  software  tools  we  alreaa,  have  available. 

The  current  belief  is  that  one  cannot  originally  write  AI  software  in  Ada. 

Direct  porting  from  AI  code  to  conventional  code  may  lead  to  computationally 
inefficient  code  being  produced. 

We  need  to  begin  with  a  better  understanding  of  requirements. 

We  need  to  distinguish  between  real  time  as  it  applies  to  avionics  and  as  it 
applies  to  human  time  frame  (give  response  on  time  for  the  pilot  to  use). 

No  learning  systems  are  as  yet  available. 

Conclusion 


Industry  is  in  a  strong  position  to  build  good  operational  Intelligent 
Knowledge  Base  Systems  for  well  defined,  narrow  applications. 

2 .  Unresolved  Issues 

How  do  we  determine  pilot  intentions?  Through  the  sensing  of  the  pilot’s 
overt  actions? 

In  the  human/machine  relationship  who  adapts  to  whom?  In  the  past,  the  human 
adapted;  now  we  are  moving  to  systems  where  the  machine  can  adapt  somewhat. 

What  does  validation  and  verification  mean  in  the  context  of  AI?  We  should 
not  expect  the  AI  system  to  perform  100Z  correctly.  It  should  be  sufficient 
for  the  AI  system  to  perform  X  times  better  than  the  all-human  crew. 

How  do  we  build  progressive  confidence  in  the  AI  system?  How  do  we  build  in 
safety  checks  for  bounding  the  AI  decisions? 

3 .  Potential  Directions 

We  need  to  become  more  realistic  in  our  expectation  of  AI  systems. 

We  need  to  define  the  goal  of  including  AI  in  a  system.  Are  we  trying  to  build 
a  perfect  crewmember  or  are  we  just  adding  another  piece  of  equipment  on  board 
the  aircraft? 

Cockpit  Implications 

1 .  Stace  of  Knowledge 

Displays  are  much  more  efficient  than  controls  for  communication  between  the 
human  and  the  EC. 

The  symbology  and  formats  on  the  displays  are  much  too  complicated  and 
cluttered . 

2 .  Unresolved  Issues 

There  is  a  need  for  better /additional  means  of  sensing  pilot  intentions. 

What  will  give  the  machine  the  capability  to  adapt  and/or  learn? 


3. 


Potential  Directions 


We  need  to  develop  better  models  of  pilot  performance. 

We  need  to  learn  more  about  pilot  preference. 

We  need  to  balance  the  technology,  to  identify  the  best  tasks  for  the  pilot 
and  best  tasks  for  the  EC. 

We  need  to  identify  when  unpredictability  in  pilot  or  EC  is  deliberate 
(predictable  uncertainty). 

We  need  to  develop  criteria  for  assessing  pilot  acceptance  and  trust  of  the  EC 

We  need  a  better  assessment  of  pilot  workload  in  order  to  determine  dynamic 
function  allocation  between  the  pilot  and  the  EC. 

J.R. 


FIG  1  STATUS 


FIG  3  KISSIOH  MAHAGER  EXPERT 
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CONCLUSION 


This  workshop's  main  thrust  was  to  aid  in  the  development  of 
a  more  efficient  cockpit  for  future  attack/ fighter  aircrews. 
Pooling  together  the  knowledge  of  the  artificial  intelligence 
specialists,  cockpit  designers,  and  aircrew  members,  this 
workshop  provided  a  forum  for  the  exchange  of  ideas  about 
hardware  and  software  architecture  which  will  make  up  the  human- 
electronic  crew  member  combination.  Such  a  combination  will 
allow  pilots  to  more  safely  and  efficiently  navigate  in  hostile 
areas,  attack  enemy  targets,  or  land  in  poor  visibility.  The 
electronic  part  of  the  crew  is  there  to  aid  the  human  aircrew, 
not  to  take  over  the  mission.  In  the  human-electronic  crew,  the 
human  will  still  maintain  overall  control.  The  goal  of  the 
human-electronic  crew  is  to  increase  the  crew's  efficiency,  while 
optimizing  workload  and  safety. 

One  of  the  main  goals  of  this  workshop  was  to  determine  how 
far  technology  and  design  concepts  have  progressed  for  artificial 
intelligence  in  the  cockpit  and  papers  presented  reflect  that 
significant  progress  has  been  made.  Also  examined  was  the 
teamwork  issue  of  pilot  inferencing  and  how  information  could  be 
efficiently  conveyed  between  the  pilot  and  the  electronic 
component.  It  is  the  conclusion  of  the  workshop  teams  that  for 
the  near  future  the  pilot  will  have  to  adapt  to  the  electronic 
member's  formats,  as  there  are  no  current  artificial  intelligence 
systems  that  can  truly  learn.  In  the  mean  time,  workshops  such 
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as  this  one  will  continue  to  provide  a  medium  in  which  ideas  may 
be  shared  among  specialists  to  further  the  development  of  the 
human-electronic  crew. 


